Re: Newbie question about db normalization theory: redundant keys OK?

From: David Cressey <cressey73_at_verizon.net>
Date: Mon, 24 Dec 2007 13:05:56 GMT
Message-ID: <U8Obj.4648$Pt6.3812_at_trndny07>


"paul c" <toledobythesea_at_ooyah.ac> wrote in message news:_wFbj.8986$DP1.987_at_pd7urf2no...

> My attitude about concurrency is likely much simpler in principle, if
> not in practice. Basically, an "ideal" rdbms would ignore concurrency!
> All a "transaction" can "know" is its data, aka the hand it's been
> dealt and this is sufficient to eliminate what some other transactions
> might be occupied with. If it regurgitates the queries the designer
> decides are pertinent to the transaction, at the "time" of update, along
> with the expected query results, and those match, then the rdbms could
> apply the transaction's expected updates, in perfect safety.

I'm not sure how to interpret the above.

In an airline reservation system, you might have the following code to keep track of the free seats:

set FreeSeats = FreeSeats -1

with the appropriate context. The DBMS needs to serialize these updates (if they are for the same flight). Failure to do so would result in a phantom update. That is, two concurrent updaters might each subract one from five yielding four, instead of the correct answer which is three if one update uses the output of the other, as it will if they are serialized.

From your previous writings, I'm just about certain you know this already. But I'm at a loss to understand what you might have meant in the above. Received on Mon Dec 24 2007 - 14:05:56 CET

Original text of this message