Matt Sergeant wrote: > I've just uploaded the first public version of DBD::SQLite to CPAN.
Again, congratulations. It looks like a fine addition to the DBDs. I have a bit of concern about your comparisons with DBD::CSV though, please see my comments below which widen the field of comparison a bit. > DBD::SQLite is a DBD driver that contains the database engine in the > driver. That means you don't need to install anything else In this it is similar to DBD::CSV, DBD::AnyData, DBD::Sprite, and DBD::Xbase -- all contain their own database engines within the drivers and don't require additional RDBMS installation. DBD::SQLite requires a C compiler or a binary version of the module, while the others do not. > uses > a single disk file for the whole database. Which can also be true of some of the other drivers (e.g. AnyData::Format::XML). It should also be mentioned that DBD::SQLite, unlike most of the other mentioned DBDs, stores its data in a machine-but-not-human readable format. > It's a type-less database, much like CSV files, but you can specify types > when you create the tables (no doubt this will be supported better in the > future). > It supports atomic commit and rollback - something you can't do with CSV. Types, and commit and rollback are in the works for DBD::CSV and DBD::AnyData, I don't know about the situation with the other engine-in-themselves drivers. It also seems to me that for users to make an informed choice, they will need a comparison between SQLite and things like MySQL and PostgreSQL. If they have existing data in various formats (Fixed Length, CSV, etc.) they will either use things like DBD::CSV meant to work with human readable formats or they will convert everything to some machine-readable format such as used by SQLite, MySQL, PG, and the other RDBMSs. So it seems more relevant to compare SQLite with that group rather than with the DBDs supporting human readable formats. -- Jeff
