Re: Guidelines to a decent support of surrogate key implementation
From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 25 May 2007 01:07:45 GMT
Message-ID: <BFq5i.218371$aG1.207497_at_pd7urf3no>
>
>
> 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
Date: Fri, 25 May 2007 01:07:45 GMT
Message-ID: <BFq5i.218371$aG1.207497_at_pd7urf3no>
paul c wrote:
> 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 >> >> >> cascade >> >>>> 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 >> >> >> cascade >> >>>> 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. >> >> >> >> Not necessarily. If User 1 has a snapshot transaction going, the >> users 2 >> and 3 can proceed >> without wiping out the data the DBMS needs to provide User 1 with a >> consistent view of the data. >> >>
>
>
> 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
Oops, sorry, I think I spelled 'germane' wrong. Might have confused the adjective with name of that famous woman I admired many years ago, probably for reason she didn't want to be admired for.
p Received on Fri May 25 2007 - 03:07:45 CEST