Re: Guidelines to a decent support of surrogate key implementation

David Cressey wrote:
> "DBMS_Plumber" <paul_geoffrey_brown_at_yahoo.com> wrote in message
> news:1180030480.560699.111200_at_o5g2000hsb.googlegroups.com...
>

>>On May 24, 9:27 am, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>>
>>
>>>CON
>>>Keys can change over time.  Consider the following:
>>>
>>>R{A, B, C} | AB --> C, and several other relations referencing R[AB]. R:
>>>{A:1, B:2, C:3}
>>>{A:2, B:2, C:2}
>>>
>>>T1: User 1 reads row {A:1, B:2, C:3}, starts a long-running calculation.
>>>
>>>T2: User 2 updates row {A:1, B:2, C:3} to {A:3, B:2, C:3} updates

>>>throughout the database. R:
>>>{A:3, B:2, C:3}
>>>{A:2, B:2, C:2}
>>>
>>>T3: User 3 updates row {A:2, B:2, C:2} to {A:1, B:2, C:3} updates

>>>throughout the database. R:
>>>{A:3, B:2, C:3}
>>>{A:1, B:2, C:3}
>>>
>>>T4: User 1 updates row {A:1, B:2, C:3} to {A:1, B:2, C:4} -- BUG!!!!
>>
>> All your example does is show that users who don't understand
>>isolation levels will create bugs.
>>
>> If User 1 was planning to update the tuple they had read, then they
>>damn well better ensure that their read is repeatable. This would
>>block User 2 and User 3.

When it comes to concurrency, I'd be happy to go timeless, given enough 'horsepower'. If not enough of that is available then I'd be happy to limit how many changes a 'machine transaction' can achieve. When you eliminate time, a lot of problems go away as do many technicalities. When it comes to locking, I'd rather have a system that single-threads updates, or at least gives the illusion of same, and requires the 'update transaction' to re-gurgitate all facts it considers germain. I know some people would object to this on the grounds, for example, that references to facts, say in the form of foreign keys, that haven't been 'read' might be germain. But I say they're not. In my parochial view, locking implementations should be measured against this attitude. For me, this is one upshot of the information principle.

At the risk of looking like I'm confusing temporal db's and concurrency, I don't say people shouldn't implement temporal db's, I just say I think there is an amenable short step that is very useful and far less complicated than what most modellers end up requiring from an engine.

p Received on Fri May 25 2007 - 03:04:20 CEST