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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 22 Dec 2007 23:25:46 -0400
Message-ID: <476dd54b$0$5281$9a566e8b_at_news.aliant.net>


paul c wrote:

> 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.
> 
> In those days, most Cics and some IMS programmmers knew the four 
> necessary conditions for deadlock and avoided at least one of them in 
> their apps.  Nowadays that's considered high science.   Jim Gray was a 
> smart guy and I hope he's still alive but the fact remains that it seems 
> that he and other concurrency experts chose to ignore the IP.  I think 
> Bob B said something quite profound recently, something like "you can't 
> manage data without data".  A corollary might be that only mystics can 
> manage without data.  Normalization theory started with the IP and 
> caught a following, no coincidence if you ask me.  The concurrency 
> theorists carried on with the IMS and other physical ways of thinking 
> and never seemed to get the idea that there might be a logical 
> concurrency model based on the IP (at least as far as I know).

IP? Intellectual property? Internet protocol? IMS programmer? ?? Received on Sun Dec 23 2007 - 04:25:46 CET

Original text of this message