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

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:r0eri.17043$fJ5.1008_at_pd7urf1no...
> Brian Selzer wrote:
> ...
>> Given a choice between a key that permanently identifies individuals and
>> a key that contingently identifies individuals, which would you choose to
>> be the primary key, and thus the target of all foreign keys? Don't you
>> see a problem with a relation that represents the histories of a set of
>> individuals where those individuals are denoted only by a set of
>> attributes that contingently identify them?
>> ...
>
> No, I don't imagine any particular problem. I'm darned if I'm going to
> get sucked into judging such shapeless questions in a vacuum, whether
> contingent vacuum or non-contingent vacuum, whatever contingent means
> here. If the word "contingent" ever has any place in a db topic, even
> though I doubt it does, it would be with reference to an application. Same
> goes for other loose lingo like "rigid".
>

I find it hard to believe that you can't discern the difference between a key where each value denotes the same individual at all possible database values and a key where each value denotes the same individual at some possible database values.

I also find it hard to believe that you don't know that the terms "rigid" and "contingent" have precise meanings in that context.

I am therefore left wondering what purpose is served by your response. I may be dense, but can you enlighten me?

>> But requiring that all key values permanently identify individuals
>> significantly limits the expressiveness of the model, cutting in half the
>> expressions that can be used to denote individuals, thereby reducing the
>> number of queries that can be formulated. Referring to my previous
>> example, a query such as "Which part has lot number 203 in location 22?"
>> could not be considered deterministic if the key, {lot_number, location},
>> were not defined, and thus should be rejected as being formulated
>> incorrectly. Without that key, there can be more than one part with lot
>> number 203 in location 22, and you can't stuff a relation value into a
>> tuple variable.
>> ...
>
> I'm glad that isn't phrased as a question, because words would fail me if
> I tried to answer it! Maybe somebody else wants to try.
>
> p
Received on Mon Jul 30 2007 - 07:43:49 CEST