Re: Newbie question about db normalization theory: redundant keys OK?
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