Re: Guidelines to a decent support of surrogate key implementation
Date: Thu, 24 May 2007 23:31:31 GMT
Message-ID: <nfp5i.20616$Qz.9647_at_trndny09>
"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.