Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbvax!unisoft!mtxinu!tim
From: tim@mtxinu.UUCP (Tim Wood)
Newsgroups: comp.databases
Subject: Re: Pro-Pre-Relational
Keywords: network,hierarchical,relational,comparison
Message-ID: <549@mtxinu.UUCP>
Date: 10 Jan 88 23:07:15 GMT
References: <2557@sfsup.UUCP> <68@coot.AUSTIN.LOCKHEED.COM>
Reply-To: tim@mtxinu.UUCP (Tim Wood - Sybase Inc.)
Organization: Sybase, Inc.
Lines: 66

In article <68@coot.AUSTIN.LOCKHEED.COM> chris@AUSTIN.LOCKHEED.COM (Chris Wood) writes:
>
>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.  [...]  In
>a relational system, the user must do join type operations as part of the
>query.
>
>2. [paraphrased, i lost the text in some vi buffer:]
> CODASYL offers a "place-near" option to physically cluster joining
> records ...
>
>How can relational implementations do this unless they know about such
>relationships?
>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.

Um, Sybase allows you to get the optimizations you speak of without
the limitations of network/hierarchical.  At a low level, it allows
the use of nonclustered index entries as data when only key values
are being accessed; so if all your search conditions are on key values
for all tables in the query (which will usually be true in a fully
normalized database), you will never do any linear scanning of rows
with different key values, and rows matching a key value are found in 
O(log(#-of-rows-in the table)) time.  The system's query optimizer picks
this strategy automatically; all the user needs is a good database design.

At the SQL level, use of stored procedures allows saving of this strategy
in the DBMS, so the database is always accessed with a pre-compiled optimal
query plan.  No application need do anything special to get the best access
path, other than conform to the database schema.  If the DBA changes the
schema, procedures using it are automatically reoptimized at the next
invocation.

>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.  ...
>   [explanation of 1-to-N mapping of acct. records to activity records]
>In a system that allows repeating fields,
>I build 4000 records in a single table.  
>On average, it should take about 10 times
>as long to examine 40000 records as 4000 records.  

Not if you've set your schema up properly.  See above.  Strictly speaking,
repeating fields aren't "relational"; in a good DBMS with the right schema, 
the compromise is not necessary.

I agree with Chris' implication (my inference?) that relational systems
have been naive about exploiting optimal storage structures.  The
trick is to use them without sacrificing data independence, which is
a unifying (not the product :-)) concept of RDBMS.
-TW

This posting represents my opinion, not necessarily that of
Sybase, Inc. or any of its other employees.  Though not required to do
this, I want to distinguish between my view of the DBMS scene and
Sybase's.
-- 
{ihnp4!ptsfa,pyramid,{uunet,ucbvax}!mtxinu}!sybase!tim