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

"paul c" <toledobythesea_at_ooyah.ac> wrote in message news:BHabj.1877$vd4.1424_at_pd7urf1no...
> David Cressey wrote:
> ...
> > It's my understanding that a consistent view of a database involves
> > everything written by prior transactions and nothing written by
concurrent
> > transactions, let alone future transactions. Concurrency is, of course,
> > more complicated than this, but this is sufficient for this
discussion.
> > ...
>
> It certainly does get complicated, IMHO that's because of the
> conventional locking implementations which for the average app
> programmer, obscure the essential problem. Often those implementations
> force the changing of application requirements when I think concurrency
> should always be part of the requirement. Logically, I don't see why a
> transaction need ever be concerned with other concurrent transactions
> although I admit such an implementation might not be considered
> "optimum" as far as performance is concerned. For example, if "time" is
> taken out of the picture by a suitable language, one could view, say, a
> bank account balance update as involving only the data the transaction
> has read plus the changes and these could all be expressed in the form
> of relations. A dbms could view the previously read data supplied by an
> updating transaction merely as constraints or assertions if you like.
> In this way, such a dbms would not have a distinguishable concurrency
> component, eg., a conventional lock manager. I'm not suggesting this
> should be implemented but to me it seems a kind of canonical view of the
> concurrency problem and possibly a good one for allowing people to
> introduce concurrency notions into an application design as opposed to
> leaving it to the vagaries of a particular implementation.
>

I was spoiled, back in the late 80s and early 90s, by working with DEC Rdb/VMS.
The locking mechanism was fairly conservative, but the app programmer was very much freed from the responsibilities for figuring out the things you describe, at least in most circumstances.

What programmers did have to program for was deadlock errors, and to be able to rollback out of the tranaction and start it again. At the time, that seemed a small price to pay.

Rdb/VMS had two concurrency mechanisms, one using lock manager, and the other using multiple versions called "snapshots". The snapshot mechanism was mainly for providing a read only transaction with a consistent view of the database while not blocking read write transactions.

I don't have that much experience with the other implementations, but it seems as though some of them place more of a burden on the programmer.

> To some extent, I think the "optimistic" implementations mimic this, but
> my complaint is that their mechanisms are usually out of the hands of
> the app programmer.
>

And that's a good thing, except in exceptional circumstances. Received on Sun Dec 23 2007 - 01:50:32 CET