Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!husc6!hao!ames!necntc!linus!philabs!gcm!dc
From: dc@gcm.UUCP
Newsgroups: comp.databases
Subject: Re: Pro-Pre-Relational
Keywords: network,hierarchical,relational,comparison
Message-ID: <395@white.gcm>
Date: 9 Jan 88 10:13:36 GMT
References: <2557@sfsup.UUCP> <68@coot.AUSTIN.LOCKHEED.COM>
Reply-To: dc@white.UUCP (Dave Caswell)
Organization: Greenwich Capital Markets, Greenwich, CT
Lines: 25
Posted: Sat Jan  9 05:13:36 1988

In article <68@coot.AUSTIN.LOCKHEED.COM> chris@AUSTIN.LOCKHEED.COM (Chris Wood) writes:
>
*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.

Now we know why he wrote this article

>FLAME AWAY, This should be fun!

Please don't flame away.  
The above example isn't a repeating group.  However it *is* true that SQL 
cat not process it efficiently.  A repeating group would be using 12 records.