Re: CODASYL-like databases

From: Rob <rmpsfdbs_at_gmail.com>
Date: Tue, 1 Apr 2008 10:35:54 -0700 (PDT)
Message-ID: <eee27cef-35bb-4c39-a5cd-0816e9b1b8d8_at_e6g2000prf.googlegroups.com>


On Apr 1, 7:34 am, "David Cressey" <cresse..._at_verizon.net> wrote:

I'm going to disagree with several points you make in your response. cdt has become so adversarial lately, I feel compelled to state that I can disagree with your pov w.o. being disagreeable.

> "Troels Arvin" <tro..._at_arvin.dk> wrote in message
>
> news:fsslgl$320$1_at_news.net.uni-c.dk...
>
> > Hello,
>
> > 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.
>
Disagree. Codd was a doer as well as a thinker. In his 1970 paper, he perceived that data dependencies in present systems (ordering dependence, indexing dependence and access path dependence) implied that "changes to the characteristics of data representation logically impaired some application programs". (I am paraphrasing here. He goes on to give examples of all three dependencies.) The economics of data processing in those days (now I think referred to as Information Technology) made these "impairments" expensive -- changes in the data representation required rewriting applications. So that from a business perspective, an investment was lost. To me, this sounds like a rather practical economic argument in favor of developing data independent representations so that building applications upon them would preserve the applications development investment.

> 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.
>
Maybe. To me, your answer seems anachronistic. In his 1980 paper "DATA MODELS IN DATABASE MANAGEMENT", Codd points out (under HISTORY OF DATA MODEL DEVELOPMENT) that "[h]ierarchical and network systems were developed prior to 1970, but it was not until 1973 that data models for these systems were defined." And "[t]hus, hierarchic and network systems preceded the hierarchic and network models, whereas relational systems came after the relational model and used the model as a foundation." This is consistent with my experience. The earliest experimental systems were System R at IBM and Ingres at UCBerkeley. I know Ingres had no existing dbms codebase. I suspect System R used classic IBM access methods (ISAM, etc.), but I doubt that the translation of SEQUEL (predecessor to SQL) employed any "native" IMS code. ORACLE brought the first commercial RDBMS to market. There was no prior product, so I'm guessing no existing codebase either.

Your response seems to be *very* specific to DEC's RDBMS offerings a decade later. In that context, you are probably correct.

In response to the OP (Troels Arvin <tro..._at_arvin.dk>): There really weren't many CODASYL-based DBMSs around before 1970, so the landscape was basically 1.) DBMS vendors were providing hierarchical dbms products, and 2) CODASYL and the Relational Model were slugging it out to determine which would provide a theoretical basis for the next, "data independent" generation of products. Personally, I believe that the Relational Model prevailed because SQL was more natural (read: English-like) and non-procedural whereas the CODASYL sublanguage(s) were programmatic and navigational. Although higher-level languages could of course be built upon CODASYL sublanguages, SQL already seemed usable by non-programmers. (Consistent w. Cressey's other observations, SQL had functionality for data definition as well as data manipulation, so that potential users didn't have to master multiple products for defining and using their databases.) In effect, SQL won the hearts and minds of product developers because it addressed a vastly larger TAM (Total Available Market) than the navigational/programmatic CODASYL.

Again, my opinion.

Rob Received on Tue Apr 01 2008 - 19:35:54 CEST

Original text of this message