<div class="gmail_quote">2009/10/26 H.Merijn Brand <span dir="ltr"><<a href="mailto:h.m.brand@xs4all.nl">h.m.brand@xs4all.nl</a>> writes, in part,</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
CSV as a database is not the way to create applications<br>
that need speed or need low memory footprints or need<br>
full ANSI-SQL support. If you need either of those, do<br>
convert CSV to SQLite or postgresql (or another database<br>
of your preference that does support all of your needs).<br>
<br>
In the DBI/DBD world,<br>
* CSV does not support types (beyond NULL, integer and char)<br>
* CSV does not support links (referential integrity)<br>
* CSV does not support speed<br>
* CSV does not support data dictionary persistence<br></blockquote><div><br>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!<br>
<br>Up to several 1000 rows, performance can be very high in SQL::Statement + DBD::CSV (well, in its earlier incarnations!)<br>I don't care for types much and the argument rages on in strongly vs weakly typed languages. We like Perl, don't we?<br>
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! <br><br>CSV does support links. See man 1 join. And SQL::Statement+DBD::CSV does joins too.<br>
</div></div><br>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.<br>
<br>Paul Beardsell<br>