Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!sun!urth!rfm
From: rfm%urth@Sun.COM (Richard McAllister)
Newsgroups: comp.databases
Subject: Re: relational flaws
Message-ID: <44357@sun.uucp>
Date: 5 Mar 88 03:35:47 GMT
References: <91@coot.AUSTIN.LOCKHEED.COM>
Sender: news@sun.uucp
Reply-To: rfm@sun.UUCP (Richard McAllister)
Organization: Sun Microsystems, Mountain View
Lines: 26
Keywords: relational flaws
Summary: There may be flaws in the relational model but these aren't them

In article <91@coot.AUSTIN.LOCKHEED.COM> chris@AUSTIN.LOCKHEED.COM (Chris Wood) writes:
>I just love it when a "real-world" need is considered "non-sensical" by
>relational theory.
>
>Other examples:
>
>   Repeating fields or groups of fields violate "normalization" and thus
>   are not generally supported even though they would frequently provide
>   noticeable increases in processing efficiency.
Nothing in the relational model prevents you from storing a group of rows
that differ in only one column as the non-varying part followed by the
deltas.  Just don't present it that way to the user who may want to join on
that column and is going to have a hard time doing it if the column values
are n-tuples

>   I helped write a DBMS that put "canned" relationships
>   on top of a underlying "relational" DBMS.  Then I wrote a report writer
>   that popped up a list of all records and their fields in the entire
>   database.  The user simply marked the desired fields in whatever records
>   he wanted, and using the canned relationships the software calculated the
>   "best" retrieval path to get the results, and produced the report.

Sounds like IBM's Query by Example front end to DB2, which does the query
optimization ("calculates the 'best' retrieval path".)  That system's about
as relational as they come.

Rich