Re: Designing RDBMSs?

Paul,

> I've looked at some of the textbooks about Oracle, and it would appear
> that there are similarities - i.e. the use of a timestamping method to
> ensure that transacations don't get in each others way.

If you've seen textbooks about "Oracle", they have almost certainly described "Oracle RDBMS" and not "Oracle Rdb" (.i.e. DEC Rdb). I don't mean to get snippy about this, but it's easy to down the wrong trail, because the names are so confusing.

Looking at the timeline you gave a URL for, it looks like Interbase diverged from what I call Rdb earlier than I had thought. I believe, but I can't find evidence for it, that Jim Starkey's implementation of Rdb eventually surfaced as a product called "Rdb/Eln" that DEC put out in about 1984. But I would have expected that to have been outlined in the history if it were so, so I'm a bit cautious about that claim.

You asked about Synchronization primitives, if you were writing a DBMS from the ground up. I know that the synchronization primitives are very different in "Oracle" than they are in "DEC Rdb". In DEC Rdb, the synchronization of data resource access is all built on top of an operating system feature called "the VMS lock manager". When VMS started supporting clusters, this became known as "the VMS distributed lock manager".

DEC Rdb's reliance on the VMS lock manager made for some interesting difficulties when it came time to port Rdb to DEC's version of Unix. They basically had to implement a VMS style lock manager in the Rdb SW.

My expectation is that Jim Starkey's DB used a very different locking strategy than DEC Rdb did. What made me say that IB was derived from Rdb was the similarities in the way the two of them set up the metadata tables. But that might have been Jim Starkey's concession to DSRI, a DEC architecture for "all" of its relational database products. So I might have been off base in my earlier reply.

And, of course, "regular Oracle" would never have been that closely linked with the features of ANY operating system, much less VMS. Portability was of the essence in "regular Oracle"

It occurs to me that all this is probably pretty boring to most of the readers of this NG.

--
Regards,
    David Cressey
    www.dcressey.com