Re: foundations of relational theory? - some references for the truly starving
Date: Mon, 03 Nov 2003 23:40:09 GMT
Message-ID: <tHBpb.4836$Oo4.2312_at_newsread1.news.atl.earthlink.net>
Mr. Badour,
Frankly, you sir (and I use that term loosely), are an ass. I am tired of
"Bob Badour" <bbadour_at_golden.net> wrote in message
news:CtOdnSqF9973SDuiRVn-gw_at_golden.net...
> "Dave Best" <davebest_at_usa.net> wrote in message
> news:ea757642.0311031305.1beca7a4_at_posting.google.com...
> > "Anthony W. Youngman" <thewolery_at_nospam.demon.co.uk> wrote in message
> news:<fHrE46GYsFo$EwWN_at_thewolery.demon.co.uk>...
> > > In article <CUYmb.86063$Ms2.64480_at_fed1read03>, daveb
> > > <davebest_at_SuPsAaM.net> writes
> > > >"Ross Ferris" <ross_at_stamina.com.au> wrote in message
> > > >news:26f6cd63.0310260541.7a6a9af9_at_posting.google.com...
> > > >> "Bob Badour" <bbadour_at_golden.net> wrote in message
> > > news:<GumdnaAjFvrJmQaiU-KYvg_at_golden.net>...
> > > >> > The values in a foreign key reference are redundant because they
> appear
> > > in
> > > >> > multiple relations. In this case, the redundancy is appropriate
and
> > > >> > necessary to represent the data.
> > > >>
> > > >> Interesting "admission", or at least an observation. Of course this
> > > >> redundancy is ONLY necessary because of the "flat earth" nature of
> SQL
> > > >> implementations.
> > > >>
> > > >> If the data were stored in a multi-valued database, or even an XML
> > > >> data store, then the redundant data could be removed.
> > > >
> > > >No, you have merely encoded the redundancy in the structural
> relationship.
> > > >
> > > Where? There is no key (foreign or otherwise) with which to do the
link,
> > > because there is no need to do a link.
> > >
> > > So yes there is a structural relationship, but there is no redundancy
> > > because no information is stored - it is IMplicit in the data store,
not
> > > EXplicit.
> > >
> > > Cheers,
> > > Wol
> >
> > The foreign key is in the logical model. Any nested relation has a
> > primary key consisting of the primary key columns of the containing
> > relation (and which form a foreign key to it) plus its own primary key
> > columns. In Pick, the primary key of a MV element is the primary key
> > of the record plus its array index.
> >
> > A relational database with relation-value (nested) attributes can
> > choose to physically store them clustered with the containing
> > relation, and so does not have to physically store the redundant
> > columns.
> >
> > The logical model of the data can be thought of as the API which a
> > program uses to access the data. This is distinct from the way it is
> > physically stored on the disk, which can be anything the vendor
> > chooses, including the Pick method of value-encoded variable-length
> > strings (so long as this representation is not exposed by the API).
>
> Dave,
>
> You have to stop and consider to whom you are replying. Wol is ignorant
and
> stupid.
>
> For instance, the relational model requires the dbms to represent all
> information as explicit data values in relations. Because of this, one can
> manipulate any information using the same simple, powerful tool: predicate
> logic. As soon as one represents information in any other way, one must
> either accept limited functionality or increased complexity or both. In
> Pick's case, it is clearly both less functional and more complex.
>
> As evidence of Wol's ignorance and stupidity, he actually thinks that
> implicit physical representations of information have some advantage. He
> lacks the cognitive ability to comprehend that the redundancy still exists
> at the logical level, and the only thing different is Pick has less
> functionality for greater complexity.
>
> How many informed and intelligent people want to pay more and receive
less?
> Can you imagine someone walking into a store and declaring he wants to pay
> top dollar for pure crap? What would you conclude about such an
individual?
>
> Received on Tue Nov 04 2003 - 00:40:09 CET