Path: utzoo!mnetor!uunet!husc6!ut-sally!ut-emx!lad-shrike!chris
From: chris@AUSTIN.LOCKHEED.COM (Chris Wood)
Newsgroups: comp.databases
Subject: Pro-Pre-Relational
Message-ID: <68@coot.AUSTIN.LOCKHEED.COM>
Date: 7 Jan 88 14:10:09 GMT
References: <2557@sfsup.UUCP>
Organization: Lockheed Austin Div.
Lines: 57
Keywords: network,hierarchical,relational,comparison


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.

NOTE: I have seen or heard of several "relational-like" DBMSs that allow
      "presetting" such relationships to allow software to automatically
      calculate a path between record types as part of determining how to
      satisfy a query.

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?

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

However, consider the following scenario:
I have a General Ledger application with 4000 account entries.  I need to
keep track of 12 months worth of data for each account.  In the relational
view, I am forced to build 2 tables, a GL table with 4000 records, and a
Monthly table with 36000 records.  In a system that allows repeating fields,
I build 4000 records in a single table.  This has a very large impact on
speed of retrieval obviously.  On average, it should take about 10 times
as long to examine 40000 records as 4000 records.  Of course the records
are much shorter in the relational implementation, and the known 
maintenance headaches of variable length records is well known.  But still,
the relational implementation is quite inefficient.

Note: a professor at the University of Texas is currently studying extending
SQL to include "imbedded relations", aka repeating groups.

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


FLAME AWAY, This should be fun!

Chris Wood   ------------------------ 15+ years playing with DBMS:
                                      SYSTEM 2000, TOTAL, IDMS, MODEL 204,
                                      ORACLE, VAX RDB, BTRIEVE (IBM/PC), and
                                      even a little IMS (Ugh!), INQUIRE, etc.