SQL::Statement unusable in major Linux distributions
paul at beardsell.com
Mon Oct 26 11:09:09 UTC 2009
2009/10/26 H.Merijn Brand <h.m.brand at xs4all.nl> writes, in part,
> CSV as a database is not the way to create applications
> that need speed or need low memory footprints or need
> full ANSI-SQL support. If you need either of those, do
> convert CSV to SQLite or postgresql (or another database
> of your preference that does support all of your needs).
> In the DBI/DBD world,
> * CSV does not support types (beyond NULL, integer and char)
> * CSV does not support links (referential integrity)
> * CSV does not support speed
> * CSV does not support data dictionary persistence
I do not thnk that DBD::CSV should be written off so lightly as that. A
database is a merely a collection of structured data. CSV provides
structure. A database management system is the set of tools around that. I
use grep, awk, sed, cut and join. And SQL::Statement. And vim. DBD::CSV
is not just merely a database import tool as you use it. I like RI (of
course) and I am prepared to manage it in the application. Dictionary
persistence? See the first line of my CSV tables!
Up to several 1000 rows, performance can be very high in SQL::Statement +
DBD::CSV (well, in its earlier incarnations!)
I don't care for types much and the argument rages on in strongly vs weakly
typed languages. We like Perl, don't we?
Referential integrity is a property of the data, not of the DBMS. RI can be
enforced by the DBMS but that is a different thing entirely!
CSV does support links. See man 1 join. And SQL::Statement+DBD::CSV does
By extention of your argument much of the recent changes to SQL::Statement
is merely aping other DBMSs and there is no real benefit. Triggers/stored
procedures/user defined functions? Really, just use
Postgress/MySQL/Oracle. Here I agree.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pkg-perl-maintainers