On 3/28/07, James Edward Gray II <james / grayproductions.net> wrote:
> On Mar 28, 2007, at 7:54 PM, Austin Ziegler wrote:
> > There's no theory behind OODBs, much less relational theory. OODBs are
> > ways to serialize your object graph.
> OK Austin, I'll give you 100% of that statement.  Let's say you are
> completely right.
>
> Who says *that* isn't useful?

James, if you look over what I've said in this thread, you'll note
that I have explicitly said that you *can* successfully store your
data. The moment you need to access the data in a different direction,
you're completely screwed.

Heck, I *use* Marshal in PDF::Writer because I *need* to store a
specific object graph and never query the data structures in a
different way.

Persistent data -- especially that which belongs to businesses -- is
often very different, though. Remember the maxim I postulated early in
the thread: data is king. The data you have is far more important than
your program, and OODBs fall down because they typically tie you to a
single object model.

As I was discussing with someone off-list, the data that I need for a
customer report is very different than the data that I need for a
summary of how many customers bought a particular widget and how often
in which locale. Object databases force you to query for a full object
even if you need a tiny portion of that object. In the putative
example I describe above, I only need to know a customer's locale
(state or province, if you prefer) -- but with an object database I
have to restore the entire customer object before I can then whittle
down the data to exactly what I need. Worse, because most people don't
know anything about data modelling (and thus make pretty bad object
modellers, too), there's a good chance that all of my orders are
reachable *through* my customers, meaning that to get to the orders, I
have to query through the customer object in the first place!

Pascal (or Date) had a good definition of the relational data model.
The relational model is tuples and attributes with associations
(relations); yes, I'm paraphrasing here.

> Ruby includes Marshal, YAML, and PStore for these uses, right?
> Arguably one of their biggest weaknesses is that they have to restore
> the entire graph before they can do anything with it right?  If an
> OODB can eliminate that one restriction, wouldn't that put it leaps
> and bound ahead of all three of these libraries?

It'd put it a couple of steps ahead, not leaps and bounds, because
you're still stuck with your single query path. If that's all your
data needs, fine. But *most* data needs much more than that, and it
must be dealt with by more than one application ultimately.

I have said a lot of things about this and how one would work with
both application and integration databases as Martin Fowler has talked
about them (and wrapping the databases in services) -- and that's
often a good thing to deal with, too, but it's sometimes not
applicable.

> I don't know about you, but I use all three of those a lot.  So it
> seems a simple OODB has some value for me.

I rarely use those in real applications. They're good for
checkpointing, as far as I'm concerned, and that's about it. I
certainly wouldn't store a customer's persistent data in them, or in
an OODB. Period.

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