From: Avi  Bryant <avi.bryant@...>
Date: 2005-03-25T19:34:48+09:00
Subject: Re: OO database concepts...


Hal Fulton wrote:
> I've been thinking about OO databases -- never having really
> used such a beast. In fact, I am not sure that OOD even exist
> in the sense that I would like.
>
> Here's one thing I'm thinking about...
>
> When one class inherits from another, we take it for granted
> that they are "type compatible." Anywhere a Mammal can be
> used, we can specify a Dog. (Insert standard discussion of
> duck typing here.)
>
> I'm thinking of the usual paradigm where a table is an ordered
> sequence of fields. Neglecting the methods (which is another
> issue entirely), we can think of the fields as instance vars.
>
> But if a have a database table of Mammals... I can't store a
> Dog in it. Hmm. I think I wish I could?

Hal, you're thinking too much in the relational model still.  Real
OODBs don't have tables, they have graphs of objects, just like in
memory.  They tend to use persistence by reachability, which means that
they have a defined root object, and any object that you can get to
from that root object - regardless of type - gets stored in the
database.  The only "table" of Mammals would be if you hung an array of
them off of the root, and you could stick whatever you wanted in that
array.  This means the database has to be strongly, dynamically typed:
each object record knows what its own class is, and thus which fields
it has.

Note that this makes it much harder for the database to do automatic
indexing the way RDBMS do.  Depending on the OODB, you may well have to
take care of this yourself, making sure that you have appropriate data
structures so that you can access any object by traversing a minimum of
pointer references and using as few large objects as possible (it's
usually a good idea to use trees of some kind for lookup rather than
massive hashtables, for example).

Gabriele mentioned GOODS.  That's a reasonable open source choice if
you want a large-scale networked OODB, although you have to be very
careful about performance because every object access goes over the
network.  I've written client libraries for both Squeak and Python (on
contract) for this, and porting the same design to Ruby would be very
doable - although the lack of a real WeakReference implementation will
make performance suffer.  If you're careful, you can achieve
cross-language data sharing with this (I've done simple demos of having
Java, Python, and Squeak all accessing the same object data).

The author of GOODS also has a simpler on-disk OODB called DyBase that
there are already Ruby bindings to, that you might want to take a look
at for smaller-scale projects.

If you have more questions about OODBs, my general advice is to find a
Smalltalker - for whatever reason, in the Smalltalk world they're still
the default industrial choice (often in the form of GemStone, but
that's an expensive package targeted at big business; some of the heavy
users are JP Morgan, Washington Mutual, and the OOCL container lines).

Cheers,
Avi