Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!eric
From: eric@pyrps5 (Eric Bergan)
Newsgroups: comp.databases
Subject: Re: relational technology flames
Message-ID: <12673@pyramid.pyramid.com>
Date: 6 Jan 88 01:07:54 GMT
Sender: daemon@pyramid.pyramid.com
Lines: 43

In article <2557@sfsup.UUCP>, prj@sfsup.UUCP (P.Jayne) writes:
> 
> >>(The difference between a network data base and a relational
> >>data base is that in a network data base some of the joins have already
> >>been done for you, and most of the rest are nearly impossible to do.)
> 
> 	More-or-less.  This is part of what should help you choose one over
> the other.  Most posters ignored me when I said relational DBMSs had
> their niche.  You make a lot of queries of the "What employees under me
> make more than I do and are left-handed" variety, you use relational.
> As far as things being "nearly impossible to do" in a network database,
> let's not confuse poor design with choice of DBMS.  I have never had to say
> "no, that's too hard to do" because of say, IMS;  the reason things can't
> change rapidly is administrative, not technical.  Most people don't see
> this at all -- the coding is the easy part.  Sorry, hackers.

	Have all the applications that you have worked on been static
entities, that didn't change as you after you had initially designed the
database?  If a network database-based application suddenly needs to
support a new query that it was not initially designed for (but has the
data for), a significant redesign may be necessary. In a properly designed
relational database, the data independence allows you to avoid this
redesign.

	Further, it is not at all unusual, after the application has
gone into production, for new requirements develop. These are particularly
nasty, since you may not be able to afford the production down-time
to reorganize a network database to support the new requirements.
With a relational database, the only significant change might be
the creation of new indices, and some of the current vendors even 
allow that to be done without down time for the database.

> >> It simply isn't true that relational systems "fail rather dismally"
> >> when they meet anything complex.
> 
> 	Ever heard of the New Jersey Division of Motor Vehicles?

	We all know of failures for almost any aspect of computer usage.
This does not prove that the technology is "bad". Just as there are
good and bad systems developed based on network databases, there are
good and bad systems developed upon relational databases. Now, if you
could prove that significantly more bad systems are developed under
relational databases than under network databases, you might have a
stronger point.