in reply to Single file RDBMS w/o system install

I have to say, I'm happy with DBD::CSV. You can have SELECT/UPDATE/DELETE, CREATE/DELETE tables .... It uses the same SQL engine as DBD::RAM i.e. SQL-Statement. Although not as performant as a MySQL or Postgresql db, it really works well. DBD::RAM is really a RDBMS in RAM, ie exit your program and the data fades away ;-) Not soo good when you use the RDBMS to store data for future access ;-)

Johan

Replies are listed 'Best First'.
Re: Using DBD::CSV
by mattr (Curate) on Nov 14, 2001 at 10:11 UTC
    Actually no, DBD::RAM offers RAM only, RAM with write to disk on command, and continuous write, in addition to supporting a number of file types including CSV and having a catalog method, which makes a table-datatype-file association for continuous read/write like other drivers. That said, I do not have much realworld experience with the driver, just wanted to correct your summary of RAM.

    I have not used the latest DBD::CSV version either, so maybe it is better now. But I have had many problems with it in particular porting a web-based sql administration program from ordinary Perl DBI to work with DBD::CSV. The biggest problems I had were having to make separate files to hold the number of records (difficulty making a unique id for a row), blank lines and duplicate records cropping up forcing periodic manual editing of the csv file, and trouble with vertical tabs (embedded from excel) and binary data (Japanese). I'm sure I pushed it too hard when I used it so if you are not doing anything serious with it (i.e. you don't really need sql anyway) you're probably safe.