Re: Newbie question about db normalization theory: redundant keys OK?
From: paul c <toledobythesea_at_ooyah.ac>
Date: Sun, 23 Dec 2007 01:41:38 GMT
Message-ID: <m1jbj.5884$DP1.3016_at_pd7urf2no>
> concurrent
> discussion.
>
> 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.
>
>
>
> And that's a good thing, except in exceptional circumstances.
>
>
>
Date: Sun, 23 Dec 2007 01:41:38 GMT
Message-ID: <m1jbj.5884$DP1.3016_at_pd7urf2no>
David Cressey wrote:
> "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.
>
>
>