in reply to Re^4: Moving from SQL to flat-files
in thread Moving from SQL to flat-files

DBM::Deep is Pure perl. It also encodes the Perl data structure in it. Neither DB_File or SQLite does that. So, it's obviously going to be quite slower and somewhat bigger.

Plus, keys() in DBM::Deep is very unoptimized. Most of the code is, right now. That's one reason I took it over.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^6: Moving from SQL to flat-files
by punkish (Priest) on May 09, 2006 at 20:28 UTC
    Actually, I don't mind bigger that much. I just wanted to confirm if I was doing something wrong, and if there was any other way of getting a count of all the records.

    Once I know all the "gotchas" I can make a decision.

    Many thanks,

    --

    when small people start casting long shadows, it is time to go to bed
      I don't think I was as clear as I needed to be. Try the following code with a hash tied against the various DBMs.
      use Data::Dumper; # %x is the tied hash. $x{foo} = [ 1 .. 3, { a => { b => 'c' } } ]; print Dumper \%x;
      Using DBM::Deep, the following will be printed:
      $VAR1 = { 'foo' => bless( [ '1', '2', '3', bless( { 'a' => bless( { 'b' => 'c' }, 'DBM::Deep::Hash +' ) }, 'DBM::Deep::Hash' ) ], 'DBM::Deep::Array' ) };
      Ignoring the random blessings, the entire data structure as Perl would see it is encoded. Using BerkeleyDB, you see
      $VAR1 = { 'foo' => 'ARRAY(0x18014f4)' };

      Note: this is as designed for BDB - it isn't meant to handle anything as the value other than a simple binary string. DBM::Deep is.


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?