From: bellamy@covax.commerce.uq.oz.au
Newsgroups: comp.databases
Subject: Re: Relational Systems set back DP by at least 10 yrs.
Date: 10 Apr 92 15:45:22 AEST
Followup-To: comp.databases
Organization: University of Queensland

In article <12109@tamsun.tamu.edu>, chandra@cs.tamu.edu (Chandrasekaran Periannan) writes:
> 
> 	This is a complete reproduction of a letter to the editor of
> Commmunications of the ACM, published in April 1992 issue. This letter was
                                           ^^^^^
	That must be it - a month long April fools day joke.

> written in response to an article by Ullman et al.
> that appeared in the Oct 91 issue of CACM
> (which was devoted to "Next Generation Databases") which said, "Relational
> Databases was one of the three major achievements of the past two
> decades".
> 
> ------------Begin letter        -----------------------------------------
> Copyright ACM 1992.
> 
> Henry G. Baker,
> Nimble Computer Corp,
> 16231 Meadow Ridge Way,
> Encino,CA 91436.
> 
> 
> Relational databases:
> 
> 	I had great difficulty in controlling my mirth while I
> read the self-congratulatory article, "Database Systems: Achievements
> and Opportunities" (Oct 1991, p110), because its authors consider
> _relational databases_ to be one of the greatest achievements of the
> past decades. As a designer of commercial manufacturing applications
> on IBM mainframes in the late 1960s and early 1970s, I can

Well I was arounin the early 70's, but since databases generally were not I'd
suggest that this 'experience' would be more of a hinderence than a plus.

> categorically state that relational databases _set the data processing
> industry back at least ten years_ and wasted many of the billions of
> dollars that were spent on data processing. With the recent arrival of
> object-oriented databases, the industry may finally achieve some of
> the promises which were made 20 years ago about the capabilities of
> computers to automate and improve organizations.
> 
> 	Biological systems follow the rule of "ontogeny recapitulates
> phylogeny", which states that every organism goes through a

"ontogeny recapitulates phylogeny" also known as the theory of recapitulation,
a theory of the late nineteenth century which these days is consider as one of
the quaint ideas of the late Victorian period [see Gould, Stephen J.(1977)
"Ever Since Darwin" essay 7].  No self respecting evolutaionary
biologist/geologist would put much faith in this.

> developmental history which mirrors the evolutionary development of
> the species itself. Data processing systems seem to have followed the
> same rule in perpetuating the Procrustean bed of the "unit record".
> Virtually all commercial applications in the 1960's were based on
> _files_ of fixed-length _records_ of multiple _fields_, which were
> _selected_ and _merged_. Codd's relational theory dressed up these
> concepts with the trappings of mathematics (wow, we lowly Cobol
> programmers are now _mathematicians_!) by calling file _relations_,
> records _rows_, fields _domains_, and merges _joins_. To a close
> approximation, established data processing _practice_ became database
> _theory_ by simply renaming all of the concepts. Because "algebraic
> relation theory" was much more respectable than "data processing",
> database theoreticians could now get tenure at respectable schools
> whose names did not sound like the "Control Data Institute".
> 	
> 	Unfortunately, relational databases performed a task that did
> not need doing: e.g., these databases were orders of magnitude slower

Slower, yes slightly, but much faster to write one off applications with. I've
just written a program using a relational database, it takes 20 hrs to run on a
MV3100.  If I had to design a flat file system, using indexes/hash keys it
would probably take almost as long - once I had written and debug the program. 
The relational program took two hrs to code and test, I'd guess the
'conventional' program would take at _least_ two days.  (I've been coding
COBOL/Fortran/... for almost 20 years)


> than the "flat files" they replaced, and they could not begin to
> handle the requirements of real-time transaction systems. In
> mathematical parlance, they made trivial problems _obviously_ trivial,
> but did nothing to solve the really hard data processing problems. in
> fact, the advent of relational databases made the hard problems
> harder, because the application engineer now had to convince his
> nontechnical management that the relational database had no clothes.
> 
> 	Why were relational databases such a Procrustean bed? Because
> organizations, budgets, products, etc., are _hierarchical_;
> hierarchies requires transitive closures for their "explosions"; and
> transitive closures cannot be expressed within the classical Codd
> model using only a finite number of joins (I wrote a paper in 1971
> discussing this problem). Perhaps this sounds like 20-20 hindsight, but
> most manufacturing databases of the late 1960's were of the "Bill of
> Materials" type, which today would be characterized as
> "object-oriented ". Parts "explosions" and budgets "explosions" were

Parts explosions were one case were the hierarchical structure always had
problems.  A part usually takes place in a many-to-many recursive relationship
i.e. was part of other parts and was in itself made of many parts.

> the norm, and these databases could easily handle the complexity of
> large amounts of CAD-equivalent data. These databases could also
> respond quickly to "real-time" requests for information, because the
> data was readily accessible through pointers and hash tables --without
> performing "joins".
> 
> 	I shudder to think about the large number of man-years that
> were devoted during the 1970s and 1980s to "optimizing" relational

or inventing new hashing routine which avoided/handled hash key collisions (all
of which had to be coded by the programmer); yes I've heard of subroutines but
counting all those bytes/chars to get records per bucket must have fried my
brain.
 
> databases to the point where they could remotely compete in the
> marketplace. It is also a tribute to the power of the universities,
> that by teaching only relational databases, they could convince an
> entire generation of computer scientists that relational databases
> such as flat files and Bill of Materials.
> 
> 	Computing history will consider the past 20 years as a kind of
> Dark Ages of commercial data processing in which the religious zealots
> of the  Church of Relationalism managed to hold back progress until a
> Renaissance rediscovered the Greece and Rome of pointer-based
> databases.  Database research has produced a number of good results,
> but the relational database is not one of them.

We are all entitled to our opinion - maybe the Greeks and Romans used their
_slaves_ to do all their coding :-)


-----
David E. Bellamy              Email: bellamy@commerce.uq.oz.au
Dept. Commerce, University of Queensland, St. Lucia, AUSTRALIA