I'm trying to figure out how whether DBIx is the family I'm looking for...
Some of you may be aware of DBD::Chart.
Its finally matured enough now (at least I hope so)
that I'd like to extend it to make every DBMS (er, rather every DBD) look
like it provides native charting ability, e.g.,
SELECT LINEGRAPH FROM
(SELECT * FROM someOracleTable WHERE this=that...)
WHERE WIDTH=400 AND HEIGHT=....
My initial assumption was that DBIx
was the "home" of such a concept (ie, doing a minimal pre-parse of SQL
to determine if a chart was requested; if not just pass things off to DBI,
otherwise, do some more heavy lifting in w/ DBD::Chart).
But after pawing thru various DBIx modules, their purpose seems
to be to minimize (eliminate?) SQL use as much as possible. I guess
I've been slinging SQL too long, but I find SQL a very useful
and capable language (esp when coupled w/ Perl 8^) esp. with the
VLDBMS systems I deal with.
Hence DBD::Chart (using SQL to build charts/graphs from data).
Q: Is DBIx where my concept belongs ?
If not, where ?
If so, are there any DBIx modules I can
cheat from to figure out how to subclass DBI wo/ having to replicate
every DBI method ? (This maybe my ignorance of Perl OO programming showing)
Soapbox for those that don't understand my POV:
DBMS's used to be just a way to store data for quick lookup based
on an index. Now they're "information engines". What's the most effective
way to convey quantitative information ? Qualitatively, ie, graphically.
So just as requesting the SUM, AVG, MIN, MAX, etc of a dataset is
common in SQL, why should specifying a LINEGRAPH/BARCHART/
GANTTCHART etc. be any different ? Beyond that I'll
defer to the classic text ("Visual Display of Quantitative Information",
Edward R.Tufte)
Regards,
Dean Arnold
