Re: CODASYL-like databases
Date: Tue, 01 Apr 2008 13:34:43 GMT
"Troels Arvin" <troels_at_arvin.dk> wrote in message
> RDBMSes are sometimes described as a reaction against network-/
> hierarchical databases. I believe that I've read that CODASYL-like DBMSes
> resulted in databases which were very hard to maintain.
> Does someone know of more concrete descriptions of what problems the old
> CODASYL-like databases resulted in?
I would describe the introduction of the relational model of data for DBMS work as forward progress rather than as a reaction against something. The early RDBMS products were, to some extent, an attempt to obtain the power and simplicity of the relational model without discarding a code base that had been based on hierarchical or network models of databases. This complicates the history.
To get back to your question, there are really two sets of problems with the prerelational DBMS products: problems inherent in the graph theory of data and problems in the implementation of RDBMS products up to that point in time. The theoretical problems are more easily discussed, and I expect that other contributors will answer that part of the question thoroughly.
I'm going to talk about the practical problems inherent in VAX DBMS when compared to VAX Rdb in about 1985. (Note: VAX Rdb did not become an SQL database until 1986). I'm choosing those two products because they shared so much code base that the comparison might actually be meaningful. VAX DBMS was a fairly good CODASYL database, while VAX Rdb gave Oracle quite a run for the money, until the Oracle Corp. bought out Rdb in 1994.
First, there's difficulty in learning. In order to build a VAX DBMS database, you practically had to become a database expert, even if the database you were building was a very simple, tinker toy database. You could build a starter VAX Rdb database with a lot less learning. This gave the initial advantage to "relational", although there's a danger here. Many people who learned just enough to build a tinker toy database stopped learning at that point, and built major databases that suffered from lack of design knowledge.
Second, there's difficulty in modifying the schema. There are many schema changes in VAX DBMS that necessitated unloading most or all of the data, and reloading the data into a new empty database. Not only that, many of these changes requires extensive maintenance work on the application programs. By comparison, many changes (such as adding a new table, a new index, or a new column to an existing table) could be made to an Rdb database without even taking the database off the air, and with little or no maintenance on most application programs.
Some of this is due to the implementations of VAX DBMS and VAX Rdb, but a large part of it is due to the difference between the graph model of data and the relational model of data. The more you learn about "data independence", the more apparent this will be to you.
Third, there's difficulty in implementing unanticipated queries. In VAX DBMS, queries that were not contemplated at the time the database was built were often either imossible to program or resulted in such disastrous performance that a database redesign was in order. By comparison, unanticipated queries on VAX Rdb databases frequently fell into the class of problems that are easily solved, and resulted in acceptable performance, sometimes requiring a new index, but otherwise not requiring any database work at all.
This is mostly due to the relational model, and not to the two implementations.
Having said this, the speed advantage in 1985 was still on the side of VAX DBMS, if the entire application was well understood, and an optimal design were made. It wasn't until much later that Rdb began to win the speed matches, and even this was due to enhancements made to Rdb, while VAX DBMS had been relegated to "mature" status.
There's more to this story, but this response is already too long.
Received on Tue Apr 01 2008 - 15:34:43 CEST