Re: cdt glossary 0.1.1 [Transaction]
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 21 Apr 2007 02:32:54 GMT
Message-ID: <qJeWh.26558$PV3.272748_at_ursa-nb00s0.nbnet.nb.ca>
>
> heh, it wouldn't be the first time and I think I have it all over my
> ankle right now.
>
> ...
>
>
> 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".
>
> ...
>
> 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
Date: Sat, 21 Apr 2007 02:32:54 GMT
Message-ID: <qJeWh.26558$PV3.272748_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
> 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".
>
> ...
In products that support "begin transaction" anything other than a "begin transaction" after a "commit transaction" is implicitly assumed preceeded by a "begin transaction" and succeeded by a "commit 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
In other words, Codd's original paper imposed no particular constraints one when or how one enforces correctness. Regardless, one can express correctness using relations and wff's. Received on Sat Apr 21 2007 - 04:32:54 CEST