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

From: paul c <>
Date: Sat, 22 Dec 2007 16:12:17 GMT
Message-ID: <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.

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.

I don't know enough about functional languages to say whether they could support this "out-of-the-box", but the D&D "comma" operator is a step in the direction of having a notation that allows "before" and "after" versions of a relvar. One might prefer to think of a time sequence when dealing with such relvars, but logically a "timeless" engine would only need to support the notion of replacement, not "before" and "after".

Just my twenty-five cents. Received on Sat Dec 22 2007 - 17:12:17 CET

Original text of this message