Re: row vs row.column level locking

Mladen Gogala <gogala_at_sbcglobal.net> wrote:
> On Sat, 17 Dec 2005 18:20:59 -0500, Serge Rielau wrote:
>
> > Well, we agree on the price tag at least.
> > Now I have no clue how statistical column correlation has anything to
> > do with locking granularity.
>
> Serge, my suspicion is the following: column C1 has some kind of
> relationship (business, logical, statistical?) with the column C2.
> Uncontrolled simultaneous update of the two columns by two unrelated
> processes might break that, possibly important, relationship thereby
> producing logical corruption of the database.
>
> I know that relational theorists cringe on the thought of related
> (derivable) data in two different columns, but sometimes it is necessary
> to have that. In the large HMO that I was working for, medical providers
> (also known as "doctors") had two types of ID: new HIPPA Id and the
> old, "local" provider ID. There was also 1-1 mapping between them, the
> local ID was the primary key, while the new HIPPA ID was made a unique
> key. Those columns were obviously related, while the relationship among
> them was not immediately apparent. Any transaction which would update
> one, without updating another would break the mapping rules,

Why would you be updating either one of them, or even both of them together? If you were updating both together, how would you know what to update them to?

> which were
> crucial in the year 2003 (deadline for the HIPPA implementation). In
> other words, database which would allow independent updates of both
> columns simultaneously would have a serious potential to cause
> significant business damage,

A database which allows a single process to update either one indepently of the other, even in the absense of any other concurrent process, is equally screwed. So it is not a matter of locking.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB