Austin Ziegler
3/25/2005 4:57:00 PM
On Fri, 25 Mar 2005 19:34:48 +0900, Avi Bryant <avi.bryant@gmail.com> wrote:
> 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).
There are three fundamental problems with OODBMSs -- and they stem
from the theory of OODBMS, not just the implementation. Avi just
pointed out the first -- the indexing on OODBMSs utterly sucks,
which means that the performance has to come from your object model,
whereas an RDBMS or ORDBMS can have additional indexing applied or
derived from how the application uses the data. The performance for
an OODBMS will therefore suffer far quicker than the performance for
an (O)RDBMS; this is due to the second fundamental problem.
Avi also suggests the second, but it's not clearly stated as a
fundamental problem: persistence by reachability. This specifically
means that they are very Pythonic: there's only *ONE* way to get at
a particular set of data. In a traditional RDBMS, you can access
data from many directions. Consider the typical example of "owned"
data, an order and its itemised details (e.g., the items on the
order). In an OODBMS, the only way to determine how many Widgets you
sold last month is to either (1) traverse the object graph for all
orders last month and visit the order details or (2) store the data
in both details and elsewhere, doubling your data storage for that
information. In an (O)RDBMS, you can simply query the order details
table without having to visit the orders themselves. This makes your
data much more accessible, and usable for ways that may not have
been envisioned by the original architects or designers. An OODBMS
locks you into a particular object model to access the data, leading
directly to the third problem.
Portability. If you need to change the object model at all in an
object database, you have to go through a full-scale migration of
the entire data store. In an (O)RDBMS, you have only to go through a
migration (and sometimes not even that) only on the tables affected.
If you want to change your OODBMS implementation, it's infinitely
harder than the already difficult problem of migrating (O)RDBMS
implementations.
OODBs are crap -- and always will be.
-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca