Least impact DB for CPAN modules

[hsmyers]

I'm at the beginning of refreshing/cleaning one of my CPAN modules Chess::PGN::EPD which among other things requires a light weight database for some of it's functions. At the moment I'm using DB_File, but I'm completely open to other possibilities— mostly what I want is to impact my users as little as possible yet maintain functionality.

As a picture of the amount of information involved (not much by today's standards) here is what shows in a dos box:

C:\>dir
 Volume in drive C has no label.
 Volume Serial Number is 7C88-9BEB

 Directory of C:\Users\hsmyers\Perl_Dev\Chess PAUSE\PGN\Chess-PGN-EPD-
+0.23\CSV

10/02/2010  09:44 AM    <DIR>          .
10/02/2010  09:44 AM    <DIR>          ..
04/02/2002  08:12 PM           196,290 ECO.txt
04/02/2002  07:39 PM            90,173 NIC.txt
04/02/2002  08:12 PM           467,540 Opening.txt
               3 File(s)        754,003 bytes
               2 Dir(s)  58,299,342,848 bytes free

C:\>wc *.txt
  2786  11138 196290 ECO.txt
  1247   6231  90173 NIC.txt
  4661  34709 467540 Opening.txt
  8694  52078 754003 total

I'm not particularly hung up on difficulty of interface, but I do want reasonable response time for queries. I'm just beginning to think about the following:

• DBD::SQLite
• DBM::Deep
• some sort of tied hash DB
• ?

So the question becomes 'What are your suggestions?'

[BrowserUk]

Given the modest size of those files, and the fact that your application (apparently) only needs hash-style, key-value access, I wonder why you're using a DB at all.

The simplest and fastest--both loading and access--mechanism would be Storable::nstore() & retrieve()

It's simple, fast, cross-platform and core. It imposes minimum prereqs upon your users and requires no "glue" code for your application.

[hsmyers]

Old habits concerning memory usage I suppose. Not really sure why I got on the DB train when I began. Given the 22 previous versions, it was a while ago! I'd just looked at Storable for another application and I must confess it didn't even register as a possibility for this problem— but from what I remember, it would probably have the least impact on the existing code and would also result in a speed up...oh hurt me again!!