Re: CODASYL-like databases

"Rob" <rmpsfdbs_at_gmail.com> wrote in message news: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.

I appreciate the effort to disagree without being disagreeable. I think you succeeded. I'm going to try to maintain the same tone.

(My newsreader is not cooperating in marking what I'm replying to with the ">" mark. My apologies if a make some errors here.)

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

Your points are well taken. I fail to understand how they disagree with what I said.

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

By "early RDMS products" I meant the large number of products that came out during the "relational derby" of the early 1980s. Perhaps my choice of words was unfortunate. I did not specifically mean Oracle and Ingress. There were several products that came out as a "now we're relational" rework of existing products. Some of these were simply the same old DBMS as before, with a thin veneer of relational interface to them. Most of what I know of these other products comes from reading commentary in c.d.t. Hopefully, other contributors will discuss those products in greater detail than I can.

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

By no stretch of the imagination did I think of my response as a definitive response to the question raised by the OP. I focussed on those two products for several reasons.

First, because I know them a little better than other products.

Second, because they illustrate the difference between a relational DBMS and a CODASYL DBMS, in terms of customer acceptance and vendor support, better than some other pairs of products might. They were built and supported by the same engineering team, sold by the same vendor, ran on the same platform, and integrated with the same programming languages. This cuts down on the extent to which extraneous factors influenced the difference between the trajectory of the two products. They provide a fairly clean contrast between the strengths and weaknesses of Relational and CODASYL, in the practical world. That's one of the things I thought the OP was trying to elicit.

As to the ten year delay, the early 1980s is the time frame during which the question of which DBMS would be the flagship DBMS, in the part of the world that I was working in. The collision between CODASYL and Relational may have happened a decade earlier in other venues, or a decade later in yet others.

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

If I understand the term CODASYL correctly, there weren't any CODASYL-based DBMS products before the DBTG task force defined CODASYL. That was, IIRC, about 1970.

Neither your comments nor mine address the difference between "relational" and SQL. That difference has been much commented on, in times gone by, in c.d.t. I expect others to comment on this difference. It may or may not be important to the discussion.

>Again, my opinion.

My opinion, too. Received on Tue Apr 01 2008 - 21:31:51 CEST