Those who persist in advocating OODBs truly show either (1) a complete lack of practical experience in actual operational management of an implemented system, or (2) a failure to fully think out the basic principles of good design. I realize that statement is provocative, but many years of experience with both relational and object DBs lead me to make it.

IMHO, the single biggest problem with the OODB model is a complete lack of integrity control. An object has attributes which in turn may also be objects. I cannot tell you how many times I have seen circular ownership rings, where ten or fifteen levels in, an attribute object claims the original object as one of its attributes.

This is, admittedly, a product of poor design, but I have had many developers declare that it is a true model of their system's reality. What it actually does is create numerous untestable pathways in the supporting application code, and databases that go belly up through no fault of the DBA trying to keep that illogical DB afloat.

A nearly perfect example supporting in support of the case against the use of OODBs is the registry DB in MS Windows. Anyone who has much experience with Windows internals knows just how fragile and corruptible that puppy is. MS keeps multiple copies of the registry DB just so they have a reference point in support of attempts to fix it when it inevitably breaks. I am also convinces that that OODB underlayment is one of the reasons Windows is such "bloatware." In my experience, the application code built around OODBs has been some of the worst, and most inefficient code I've ever seen.

Relationals, on the other hand, can use built-in relational integrity checks to prevent this type of foul design from ever becoming reality. Yes, you can turn integrity checks off, but any decent DBA, faced with that need for performance reasons, would also write scripts to do periodic and frequent integrity checks. Another benefit of using the relational DB to store objects is the design discipline it imposes to accurately and logically define an object and its attributes. Tables are objects; columns are attributes; attributes that are also objects are foreign keys. What could be simpler? All of the esoteric object model terminology really boils down to just the previously stated basics.