punkish has asked for the wisdom of the Perl Monks concerning the following question:

A long time I ago I asked for the wisdom of using BDB instead of a SQL db for creating a web-type app.

I quote myself --

On a related note -- I find the whole concept of Bdb very fascinating. Perhaps because it is a novelty to me after years of getting bored by rdbms and SQL. However, I find little or no discussion of using Bdb as the backend of websites. The reasons seem obvious -- Bdb is not relational, and while some relational stuff can be emulated, well, heck, it was just not designed to answer the kind of questions a rdbms can. Still, there is something elegant about everything being contained in a hash that can be loaded in memory, all self-contained, clean... like a single, shiny object. Any insights?

The wisdom I came back with was the SQL provided flexibility that a hash db would not be able to.

In a recent thread, dragonchild, who always has wise insights to offer, suggested I ditch DBD::SQLite in favor of DBM::Deep. For that specific application it might be too late (a lot of SQL coding already done), but for future projects I might seriously consider DBM::Deep. The attraction is in it being pure-perl, so moving apps from one 'puter to another, from Mac to Win to Linux, from home to ISP, etc., would be a piece of cassata.

The question, however, still remains -- how do I do SQL-type queries with a hash-based db? 

$db->{my_complex} = [
        'hello', { perl => 'rules' }, 
        42, 99 ];
print $db->{my_complex}->[1]->{perl}, "\n"; # easy

# however
.. print all records that 'rule' # difficult

[download]

Any examples that I could follow up on where DBM::Deep type db has been used to create a web-app? And, I am not talking of a SQL/hash hybrid where SQL data are taken out and more static (less dynamic) hash db created to improve performance. Instead, I am looking for examples of moderately complex, relational db structures implemented with a hash db.

--

when small people start casting long shadows, it is time to go to bed

Replies are listed 'Best First'.
Re: Wisdom of data in hashes vs. SQL
by cmeyer (Pilgrim) on Jun 13, 2005 at 19:11 UTC

    I am a big fan of MLDBM for simple databases. I am not familiar with DBM::Deep; I'll have to give it a look. However, I prefer a relational database, once the data design gets very complicated. There's lots of functionallity in relational databases that can be leveraged against. (Aside: any English whizzes like to correct or corroborate my use of "leveraged" there?)

    If your $db is a HoH type structure then it is easy to pull certain records from it with a little Perl:

      # store some stuff in the "database":
  $db->{ record_1 } = {
    greeting => 'hello',
    perl     => 'rules',
    etc      => [ 42, 99 ]
  };

  $db->{ some_other_record } = {
    greeting => 'Oi, gente',
    perl     => 'r0x0rs',
    etc      => [ 38, 45 ]
  };
  # and so on

  # now find keys of all records that "rules"
  my @keys_of_records_that_rule = grep {
    $db->{ $_ }{ perl } eq 'rules'
  } keys %$db;

    [download]

    -Colin.

    WHITEPAGES.COM | INC

[reply]
[d/l]
[select]

      Sticking information into a RDBMS is a good idea in my experience, here's some reasons:

      • It gives you a data model that's independent of your language and application, and potentially even RDBMS software. This can be very useful if you ever need to switch languages, which has been known to happen.
      • For projects that grow to be large, you can use an separate machine as your database server.
      • It's a solution that's well understood by people who develop software, which is a good thing if your code will ever be maintained and built upon by others.

      On the other hand, sometimes throwing things in a full-blown RDBMS is overkill, and Perl hashes are very very fast. So, like many things it depends on your situation. I really think that knowing both ways of storing data is extremely valuable, it's part of fully grokking TIMTOWDI. :)

      "There's lots of functionallity in relational databases that can be leveraged against. (Aside: any English whizzes like to correct or corroborate my use of 'leveraged' there?)"

      Don't end a sentence in a preposition without mentioning to the object of the preposition! To quote Winston Churchill, "This is the kind of impertinence up with which I shall not put." :)

      If I were to re-write your sentence, I would write somethng like this:

      Relational databases have a lot of functionality that can be leveraged to speed up development.

[reply]
        I like the comment about giving you a data model independant of language and application. After all, even though, for example, I may prefer Perl over other languages, another person/department may prefer another language.

        And at the end of the day, it's the data that's most important.. so being able to share it is a big plus!

[reply]
Re: Wisdom of data in hashes vs. SQL
by dragonchild (Archbishop) on Sep 24, 2007 at 15:17 UTC
    This reply is late in coming, but here are some thoughts after maintaining DBM::Deep for about 2 years, in no particular order:
    • SQL is relational - it's all about set theory. Set theory is great . . . until it's not. Look up Object-relational impedance mismatch. 90% of what most people do is object-oriented, not set-oriented. Heck, I'm a DBA and I still do most things object-oriented in my code.
    • Your specific question is answered using grep.
    • If you're interested, I started a project last year called Presto, based on DBM::Deep. It's still very much in its infancy, but the idea is that you can have a DBMS (built on top of DBM::Deep) that doesn't suffer from the O-R impedance mismatch. (Note: DBMS, not RDBMS). I'd love help with it, if you're interested.
    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?
[reply]

Back to Seekers of Perl Wisdom