Re: A pk is *both* a physical and a logical object.

From: Cimode <cimode_at_hotmail.com>
Date: Thu, 12 Jul 2007 10:19:58 -0700
Message-ID: <1184260798.451810.60010_at_g4g2000hsf.googlegroups.com>


On 12 juil, 18:25, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:1184247582.799847.27210_at_o61g2000hsh.googlegroups.com...
>
>
>
> > On Jul 12, 2:15 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> > > "Jan Hidders" <hidd..._at_gmail.com> wrote in message
>
> > >news:1184241371.515071.251680_at_k79g2000hse.googlegroups.com...
>
> > > > On 11 jul, 22:25, Cimode <cim..._at_hotmail.com> wrote:
> > > > > Furthermore...
> > > > > <<Technically a PK is *only* a physical implementation device, not a
> > > > > logical concept at all.>>
>
> > > > `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> > > > `it means just what I choose it to mean -- neither more nor less.'
>
> > > > `The question is,' said Alice, `whether you can make words mean so
> > > > many different things.'
>
> > > > `The question is,' said Humpty Dumpty, `which is to be master --
> > > > that's all.'
>
> > > > ;-)
>
> > > > To answer the question, I think that is quite simple. As defined in
> > > > the relational model it is a logical concept. As far as I know the SQL
> > > > standard does not state that a PK implies an index (but I could be
> > > > wrong) and then it is also there a logical concept. If it does imply
> > > > an index then it is mixed concept because it has both logical and
> > > > physical consequences.
>
> > > > -- Jan hidders
>
> > > It was my understanding that the relational model defines keys, but not
> > > primary keys. That is, any candidate key is as much of a key as any
> other.
> > In a relational perspective, the term *primary key* was first used by
> > Codd to designate a specific unique identifier that allows to
> > distinguish tuples.
>
> > > It was my understanding that certain schools of data management,
> including
> > > the SQL school, adopted the convention of naming one candidate key as
> > > primary key, and of making all FK references refer to that key, where
> > > possible. I can see, and use, that practice myself. But I can't see
> where
> > > the relational model necessitates it.
> > Who cares what SQL schools of *management* have to say about
> > relational model?
>
> Please don't confuse "management" with "data managment".
I think I misread your comment (did not mean to sound offending). I thought you were advocating that SQL schools of data management have any relevance anymore as to what should and should not be relationally sound. Quite frankly, I do not pay any attention to anything that is SQL related (except to make a living).. Received on Thu Jul 12 2007 - 19:19:58 CEST

Original text of this message