Re: DB clasical structure violation

> And why would you suggest defective technology that was discarded 20 years
ago?

I agree with the point that hierarchical or network databases are worth examining. The gradual replacement of hierarchical and network DBMS packages by relational DBMS packages is actually an interesting history. It's oversimplifying to say that all those earlier databases were simply "defective". Many of them were quite solid. In fact, there are still applications today that are running under "pre relational" DBMS packages.

I got into databases just when relational was becoming popular, myself. So my contact with pre relational DBMS packages is limited to what I learned from colleagues. I'm thinking of VAX DBMS. Although I never built anything in VAX DBMS, I know it supported atomic transactions and concurrent users, and did so very well. I'm not sure, but I believe it also had good mechanisms to support database backups. The network databases that ran on IBM mainframes were as robust, or even more so.

What's the point of this, some 25 years later? Merely this: that there are some features of DBMS packages that were treated as minimal features to be even considered a "serious database package" that predate widespread acceptance of the relational model. The idea that each user is entitled a transaction environment that is atomic, consistent, isolated, and whose outcome is durable (acronym ACID) had already been accepted in the pre relational era.

When relational databases came into their own, the best of the breed offered all of those features of the pre relational state of the art, except for those features that were fundamentally obviated by the relational model itself. In those cases where the old feature made no sense in conjunction with the relational model, the best of the breed offered other features. The flexibility and power of those new features accelerated the acceptance of the relational DBMS packages.

Now sometimes the debate between RDBMS and OODBMS enthusiasts starts to hinge on differences like multi-user concurrency and ACID instead of on differences between the two data models. At that point, it becomes relevant to point out that features like ACID have already survived the migration from one data model to another, and it's possible, even likely, that they should do so again.

Regards,

    David Cressey Received on Tue Jun 25 2002 - 17:19:41 CEST