On 2/16/07, Giles Bowkett <gilesb / gmail.com> wrote:
> Anyway, if anybody does have time for some debunking, or indeed some
> plain old bunking, that would be nice, and if you can do it without
> insulting anyone I've made friends with, well, that would probably be
> easier for me personally, in case I wanted a second onion or
> something.

Fundamentally, OODBs are based around the idea that if OO is good
development practice, it must be good data storage practice. This
concept is, well, flawed. (That's a charitable description, really.)
The problem is that OODBs tend to lock you into a single object model
(of your own devising, no less) and the moment you discover that you
need an alternate way of querying the data (what do you *mean* you
need to be able to summarize all of the sales of this item? I only
have my data organized by customer!), you're screwed.

The number one thing forgotten by OODB and XMLDB enthusiasts is that
the data is king. Not the representation of the data, but the data
itself.

Relational databases -- such as they are -- get this right. There's no
One Right View to data, but there are ways of Relating data. Mix the
relations properly, and you can have many different views -- and the
objects that can be pulled from them are just as complex.

http://qurl.com/lk792 (Joel on Software Forum) shows some of the usual
ignorance from OODB proponents, but there are some gems from the
people who know better:

    I read an article a while back that made a good case against OODB's.
    I can't remember where it came from, but the main point was this:

        Data outlives paradigms.

    In other words, with a flat set of data to work with, you can always get it
    to work with whatever the programming flavor of the day is. But when you
    stuff that same data into an object-oriented model, you're stuck with that
    model, even when OOP has been replaced by the next big thing.
    -"Chris"

A year later, another discussion broke out:

    http://qurl.com/mbqsp

Two good points from that discussion:

    [...] The "impedance mismatch" has been talked about since
    the early 80's, when OO first started appearing. [..]OODB's
    tend to fall into the "what is OO" trap; they either try to be
    tightly coupled to a particular language [...] or they are so
    generic that they end up competing directly with RDBMS's
    - and losing, since DB customers are enormously conservative
    [...] older database veterans know that many OODB's are
    often just CODASYL [network]... databases with many of the same
    problems and issues that hierarchical databases have always
    had.

    Those who think there is some vast conspiracy to keep "better"
    OODB's from winning are just silly and don't know their history
    - DBMS's are the perfect example of how those who don't know
    history are doomed to repeat it...

    - x [builds relational databases engines]

and:

    You are making a fundamental mistake that will haunt future
    developers / enhancers of your system forever.

        THERE IS NO SUCH THING AS HEIRARCHAL DATA.

    Heirarchies are a VIEW of data, from a very tight perspective.
    Change your perspective and the model falls apart.

    Organise your data according to a properly normalised
    relational model and you will have the flexiblity to grow and
    change as future needs might require.

    -HeWhoMustBeConfused

Again, this was raised in 2005: http://qurl.com/w54vq

This one has someone who is a little more active about defending
OODBs, but still makes a lot of the fundamental mistakes.

Finally, it's always instructive to read Fabian Pascal or Chris Date:

    http://dbdebunk.com/
    http://www.inconcept.com/JCM/March2004/Pascal.htm

That's about all I have time for. The number one problem from my
perspective is data lock; the number two problem is vendor lock.

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca