Re: Surrogate Keys: an Implementation Issue

"J M Davitt" <jdavitt_at_aeneas.net> wrote in message news:6f0yg.40617$u11.11553_at_tornado.ohiordc.rr.com...
> [big snip]
>
>> What does that have to do with the fact that Bob just updated the wrong
>> row?
>
> The wrong row? What was wrong about it? The database was
> told, for example, "Make Suzie's record look like this."
>
> The confusion arising because "Suzie is George and William
> is Suzie but Bob thought George was still Suzie" isn't
> going away just because you slap another value on all your
> records; you're just moving the confusion around.
>
> Surrogates aren't going to solve the problems stemming
> from the fact that Bob is working on a stale and partly
> wrong representation of the data.
>
Sure they are, because with surrogates you can determine with certainty whether or not the row you're working on still exists in the database and has the same values for all columns prior to committing the changes. It is not possible to update the wrong row if it is addressed with a surrogate key.
>
>> 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.
>
> Your list is too short; there are more alternatives. We
> don't have to wait for Bob and a surrogate isn't going to
> solve the problem without creating another problem.
>

Yes? What are they? And what other problems are created by using surrogates?

>>
>>>You are a vociferous ignoramus. It suffices to observe that fact.
>>>
>>>[remaining nonsense snipped without further effort]
>>
>>
Received on Thu Jul 27 2006 - 14:08:49 CEST