Re: Surrogate Keys: an Implementation Issue
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 19 Jul 2006 17:05:50 GMT
Message-ID: <ODtvg.208160$iF6.29803_at_pd7tw2no>
>
> I'm not really suggesting a system-supplied key, because the sytem
> would never supply it to anyone. (Except in case the user does not spec
> a PK, in which case it is provided. but in a different capacity ---
> this is perhaps cause for confusion.)
>
> On this issue, shouldn't the TTM be silent? I was under the impression
> it made no attempt to discuss implentation.
>
Date: Wed, 19 Jul 2006 17:05:50 GMT
Message-ID: <ODtvg.208160$iF6.29803_at_pd7tw2no>
Paul Mansour wrote:
> paul c wrote:
>
>> A system-supplied CANDIDATE key seems no more a bad conclusion than a >> system-supplied date but I suspect there are readers here who would >> prefer to complicate the environment by dragging in various code >> standards or other arbitrary inventions. TTM suggests this very thing >> in its 'RM strong suggestions' and can be found online although the book >> goes into more detail and IIRC avoids using the to me risky word >> 'super'. It also doesn't pre-suppose a '32-bit' value - eg., that >> could have wrap-around problems. Maybe it's another argument for always >> using views at the application level.
>
> I'm not really suggesting a system-supplied key, because the sytem
> would never supply it to anyone. (Except in case the user does not spec
> a PK, in which case it is provided. but in a different capacity ---
> this is perhaps cause for confusion.)
>
> On this issue, shouldn't the TTM be silent? I was under the impression
> it made no attempt to discuss implentation.
>
p Received on Wed Jul 19 2006 - 19:05:50 CEST