Re: Surrogate Keys: an Implementation Issue

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 27 Jul 2006 18:20:07 GMT
Message-ID: <rt7yg.27465$pu3.363556_at_ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> Brian Selzer wrote:
> 

>> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
>> news:PPMxg.21411$pu3.353655_at_ursa-nb00s0.nbnet.nb.ca...
>>
>>> Brian Selzer wrote:
>>> ...
>>
>> I know what an external predicate is. What does that have to do with
>> the fact that Bob just updated the wrong row? How could you prevent
>> that in application code, or in the middle-tier? You can't, unless
>> you either (1) lock the row until Bob gets back from Tahiti, or (2)
>> use a surrogate to guarantee that the row that's about to be updated
>> is the same as the one that was read out.
>> ...
>
> This paragraph shows a muddling of different ideas.

It shows profound confusion too. Using any candidate key means it is the same row, logically, even if it is in a different location. As long as the logic is correct, who gives a shit about the rest? Received on Thu Jul 27 2006 - 20:20:07 CEST