Re: What makes an OODBMS different from an RDBMS?

> 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.

Based on the above, it seems rdbs provide better reliability/recoverability than oodbs. In a device like the PocketPC, the "in-memory" is the persistent storage leading to simpler implementations (ie XDb engine is only 220KB). Over time secondary storage devices like hard-disks may become less prevalent as primary storage (RAM or other) become cheaper. Already 256MB of RAM can be bought for as little as $25.

> 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.

I agree making an oodb multi-user is quite a challenge. Hopefully, committing dirty pages to a disk will a thing of the past soon, making things easier, as it already is on PocketPC.

> OODBs claim to create a much richer set of tools for structuring data,

Complex data structures are easier to create/manipulate in an oodb like XDb vs rdbs. Here are some examples:

http://www.xdb1.com/Example/Ex037.asp
http://www.xdb1.com/Example/Ex038.asp
http://www.xdb1.com/Example/Ex038.asp
http://www.xdb1.com/Example/Ex039.asp
http://www.xdb1.com/Example/Ex040.asp
http://www.xdb1.com/Example/Ex041.asp
http://www.xdb1.com/Example/Ex042.asp
http://www.xdb1.com/Example/Ex043.asp
http://www.xdb1.com/Example/Ex044.asp
http://www.xdb1.com/Example/Ex045.asp

> 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.

While the physical requirements for reliability will reduce the performance of any data storage model, and maybe oodbs currently are not strong in this aspect, the manner in which oodbs resolve relations give them a significant edge in performance which can be demonstrated in benchmarks.

> 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.

You are assuming that point B can only be arrived at from point A and those people have not been fully successful so far. I guess some of us are trying to get to point B from point C.  

> > 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.

Is there a website for more information on the mentioned language/design? Received on Tue Nov 27 2001 - 02:23:04 CET