Re: sql tables

"David Cressey" <cressey73_at_verizon.net> wrote in message news:FyvPi.5420$q42.2851_at_trndny06...
>
> "Roy Hann" <specially_at_processed.almost.meat> wrote in message
> news:LJKdnSs3w_-6H5PanZ2dnUVZ8taknZ2d_at_pipex.net...
>> I mean precisely that: attach. Construct a tuple that represents your
>> proposition, and then *attach* a synthetic value that is chosen precisely
> so
>> that it is unique (usually the next sequential number in practice), and
> call
>> that your primary key. And that makes me sad.
>
> In that case, I guess you and I are on the same page. I said, and meant,
> "declare a primary key". Sometimes it's not possible to declare a primary
> key. More often than not, this means there has been a slip up in the
> analysis and design.

I was pretty sure we would turn out to be on the same page. But I fear the situation in the wild is worse than you think. You say "sometimes it's not possible to declare a primary key".

I would fall down in a swoon if I met a progammer today who agreed it might impossible to declare a primary key. Virtually no one would recognize that situation because, as I said earlier, it is considered "best practice" to *always* introduce a spurious attribute for a synthetic value and call that the primary key. The problem you describe would simply never be revealed.

None of this is to suggest that synthetic keys and surrogate keys do not have their place. They are essential, in their proper place.

Roy Received on Fri Oct 12 2007 - 00:02:12 CEST