Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!uvaarpa!mcnc!gatech!ukma!psuvm.bitnet!uh2
From: UH2@PSUVM.BITNET (Lee Sailer)
Newsgroups: comp.databases
Subject: Re: Pro-Pre-Relational
Message-ID: <29275UH2@PSUVM>
Date: 8 Jan 88 14:59:51 GMT
References: <2557@sfsup.UUCP> <68@coot.AUSTIN.LOCKHEED.COM>
Organization: Penn Sate Erie--School of Business
Lines: 82

In article <68@coot.AUSTIN.LOCKHEED.COM>, chris@AUSTIN.LOCKHEED.COM (Chris Wood) says:
>
>Just for the heck of it, I will give you a positive reaction to
>pre-relational technology.
>
>There are/were a number of "good things" about network/hierarchical models:
>
>1. Navigation between record types (relations/tables) is automatic in a
>hierarchical system.  That is, in a Hierarchy, there is one and only one
>path between two nodes, and that path is by definition already set up.  In
>a relational system, the user must do join type operations as part of the
>query.
>
     
It is only "automatic" if you want the path that was chosen by the designer.
If you want any other path, you have to twist and squirm.  IF the
application will only need one or two paths, the H is fine.  If you
need many paths, or if you MIGHT need many paths in the future, the
H is not enough.
     
When H was all there was, people naturally found all the Info Systems
that were easy to implement using the H approach.  These systems worked
then and they still work, and there is no reason to change them.
However, many procedures are very hard to do in an H system, and if
you need one of them, you're stuck.
>
>2. CODASYL/Network DBMSs had a little feature called "Place Near" that
>allowed related record occurrences of more than one record type to be
>physically clustered, thus optimizing performance of retrievals.
>
>How can relational implementations do this unless they know about such
>relationships?
>
     
Concepts like place near do not always optimize performance.  For example,
a programmer might navigate the database from the wrong entry point (from
the point of view of the "place near").  The criticism of Network Systems
is that they REQUIRE programmers and end-users to know too much about
the physical implementation before they can write efficient queries.
     
Likewise, the designed in "place near" might seem like a good choice
when the system is implemented, but turn out to be the wrong choice when
users start accessing the database.
     
Modern design strategies try to delay the desicions about physical implementati
on as long as possible.  Also, they try to provide the capability of
changing the underlying disk stu=ructures without breaking any of the
applications.   ANY DBMS must be able to collect performance statistics
at run time, so that the Database Manager can see that the records in X
tend to be accessed together with the records in Y, and see that X and Y
are stored on the same cylinder, or different disks, or whatever, to
improve performance.  In fact, there is NO reason that this monitoring and
remodeling of the disk structures could not be done automagically by the
file system, relieving users of the burden completely.
     
>3. Many hierarchical and Network DBMSs allow repeating fields and even
>repeating groups of fields.  Relational "purist" violently object to this
>on the grounds that it is not "normalized".
>
     
Nobody is forcing you to normalize your underlying relations.  In
most cases, normalization is better.  In some cases it isn't.
     
The rational for normalization is that certain types of common mistakesthat pro
grammers make are less likely.  If your programmers don't make those
particular mistakes, then don't normalize.
     
Case I.  Your programmers don't make those mistakes because the application
doesn't call for those particlualr kinds of database access.  You're
OK til the user needs change.
     
Case II.  Your programmers are brilliant.  Your in deep trouble.
They are about to quit.
     
>----------------------------MAIN POINT--------------------------------
>
>Not everything in hierarchical/network technology is bad.  We should learn
>from both our successes as well as our mistakes.  I think that some of the
>good features of these "old" technologies should be salvaged, and
>incorporated into relational implementations.
>