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@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.
>

If it can never be exposed, then it is hardly a key as far as the db interface is concerned and all you're asking is whether an optimization is possible using a 32-bit value to indirect some other values - if you don't think you'll run out of room, go ahead, what's it got to do with db theory?

p Received on Wed Jul 19 2006 - 12:05:50 CDT