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

"Jan Hidders" <hidders_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.

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.

On another subject, just what *is* the distinction between "logical" and "physical". Over the decades since James Martin wrote on the subject, there seems to have been considerable drift in what the terms actually mean. Perhaps we have too many Humpty Dumpties in the field! Received on Thu Jul 12 2007 - 15:15:05 CEST