Re: What makes an OODBMS different from an RDBMS?

James wrote:
> Based on the above, it seems rdbs provide better
> reliability/recoverability than oodbs.

They start with relying on atomic page writes, ordered in the order the writes are sent to the disk (this isn't true with most disk drives now which re-order writes), and upon that axiom, they build upwards. All data is paginated, every page write has a transaction-sequence-number (TSN) written on the start and end of every page, no pages that form a partial transaction are committed to disk until the undo information has first been committed to a log file and physically written, etc, etc, it's a whole world of pain :-). If the machine crashes and comes back the DBMS takes one look at the log, checks that all recently-committed pages have the correct TSN's at both ends, and if it finds log entries for partial transactions it can back out those partial changes leaving only whole transactions. In order to minimise and provide definition to "recently" the DBMS has done checkpointing, where everything prior is flushed and asserted to be good and complete. It takes lots of care to get right, but is done with good reason. Banks lose whole transactions frequently and survive, but losing part of a transaction makes money vanish into thin air, it's not survivable.

> Already 256MB of RAM can be bought for as little as $25.

Even radiation-hardened RAM has a known error rate. RAM will never replace multiply-redundant permanent storage.

> Hopefully, committing dirty pages to a disk will a thing of the past
> soon, making things easier, as it already is on PocketPC.

No chance of that I'm afraid.

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

Obviously. So what? For transactional reliability in the face of hardware failure, the methods I described above (pagination, TSNs, logging, etc) and a whole lot more (RAID etc) are mandatory. And believe me, many folk have tried to use OODBs for mission-critical data. Sometimes they succeeded, but never without either significant unseen and ongoing risk, or spectacular competence in largely avoiding it, usually with no thanks being due to the OODBMS vendor. Relational DBMSs are largely able to manage transactions correctly without such risks.

At this point, I think I've thrown down the gauntlet obviously enough. Perhaps some OODBMS vendors would like to discuss how they address the points I've raised?

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

Good luck! It clearly can be done (DMBS theory and practise had to originally come from somewhere!) but you'd be well advised to do a lot of reading about what was discovered by DMBS engineers, especially from System-R on. It'll save you the thousands of man-years of mistakes and wrong turnings that was spent developing those techniques. Unless you plan to live a lot longer than me, that would have to be classed as a Good Idea :-).

> Is there a website for more information on the mentioned
> language/design?

It's not ready for public discussion yet. I'm only now turning it from a research toy into a production system (after 18 years and counting:-) It will suffer for not having an object-oriented storage engine, but the mapping to SQL is still useful enough.

--
Clifford Heath, ManageSoft Corporation