Re: cdt glossary 0.1.1 [Transaction]

From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 21 Apr 2007 02:14:24 GMT
Message-ID: <4seWh.103136$6m4.83017_at_pd7urf1no>


Bob Badour wrote:
> paul c wrote:
>

>> Brian Selzer wrote:
>>
>>> "paul c" <toledobythesea_at_oohay.ac> wrote in message 
>>> news:383Wh.100591$DE1.26701_at_pd7urf2no...
>>>
>>>> Brian Selzer wrote:
>>>
>>>
>>> ..
>>> Codd (1970) defined consistency using the terms "state" and the 
>>> phrase "instantaneous value." And later emphasized it: "It is 
>>> important to note that consistency as defined above is a property of 
>>> the instantaneous state of a data bank..."
>>> ...
>>
>>
>> I don't know why he used the adjective "instantaneous" to describe a 
>> value.

>
>

> I am sure he used it for exactly the same reasons mathematicians use it
> to describe instantaneous slopes etc. The word identifies one (possibly
> indeterminate) value among many. May I politely suggest you are allowing
> the chaff to wind around the axle.
> ...

heh, it wouldn't be the first time and I think I have it all over my ankle right now.

...
> I find it fascinating that Selzer cannot get out of the begin
> transation/commit transaction mental box. If one has sufficient power
> available to describe every possible change as a single statement, one
> simply has no need for separate transaction boundaries.
> ...

I don't have any problem with "begin transaction" in a programming language, but have always found it hard to dig why a dbms would support such an idea. But "Commit" bothers me a lot, even in a programming language, because I don't see how any other statement that could follow it would make any sense except for "begin transaction".

...
>
> I am not certain Codd ever suggested deferring constraints. Do you have
> a reference?

It is this little bit from 1970 that seems to catch my eye every time I look at that paper: "There are, of course, several possible ways in which a system can detect inconsistencies and respond to them. In one approach the system checks for possible inconsistency whenever an insertion, deletion, or key update occurs. Naturally, such checking will slow these operations down. If an inconsistency has been generated, details are logged internally, and if it is not remedied within some reasonable time interval, either the user or someone responsible for the security and integrity of the data is notified. Another approach is to conduct consistency checking as a batch operation once a day or less frequently. Inputs causing the inconsistencies which remain in the data bank state at checking time can be tracked down if the system maintains a journal of all state-changing transactions. This latter approach would certainly be superior if few nontransitory inconsistencies occurred."

I hope I've cut and pasted that right. After all this time, I'm inclined to take words like "nontransitory" with a grain of salt, since time makes any old quote become out-of-context except for the literalists of the world.

p Received on Sat Apr 21 2007 - 04:14:24 CEST

Original text of this message