Re: What makes an OODBMS different from an RDBMS?

James wrote:
> An oodb, like XDb, is not multi-user,...

Should be "An oodb like XDb is not multi-user" (note the absence of the comma). Most oodb's simply memory-map a file, and pretend that because the "in-memory" data-structures are now backed by persistent storage, this somehow qualifies them for the title "database". Obviously there is a lot more detail to such an implementation, but the reality is that although the results may be superficially impressive, you wouldn't generally want to entrust any nonrecoverable data to such a system.

You seldom know when the VM system will actually commit any dirty pages to disk, or whether such writes will be ordered in any fashion that would allow recovery of the data in the event of a crash. If you want concurrent access to the data, you'll probably find that the data structures themselves the subject of lax access controls, so that even if you can find programmers who can write correct threaded code, the oodb provides insufficient support for folk to get it right. Perhaps one programmer in fifty believes they can write correct threaded code, and of those, maybe one in fifty actually can. All up, today's OODBs are a recipe for project failure - I've been a spectator (friend of the participants) at some monumental failures of this kind. All this despite the good work of the OODB vendors, who are sometimes aware of the issues and have tried hard to find ways to make them less problematic.

OODBs claim to create a much richer set of tools for structuring data, but the simple truth is that the performance and structural limits inherent in relational DBs are not imposed mainly by the relational model, but by the physical requirements for reliability. These physical requirements are largely ignored or glossed-over by OODB vendors.

There have been oodbs built that have a proper multi-user reliable storage engine underneath. HP for example did some interesting work in the IRIS project back in the late 80's, using the storage engine from HP Allbase SQL. The raw performance doesn't (can't) match the claims for less reliable oodbs, but I believe that it's the right path. Reliable OODBs can be built, but it requires a ground-up design by DBMS engineers, not the kind of object-optimists that built most oodb products.

> Although it is an apple-to-orange comparison, an oodb, like XDb, is
> self-describing. Each object has the capability of acting as a
> template for its instances, and instances have the capability of
> acting as templates for their instances and so on.

Good model. I've been using such a language (of my own design) since 1983 and find it very powerful. I even tried to build a reliable storage engine for it once, but it would have been a life's work :-). I'm now in the middle of a (slightly stalled) project to build an SQL mapping for it.

--
Clifford Heath, ManageSoft Corporation