Re: cdt glossary 0.1.1 [Transaction]

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 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.

   Perhaps he chose to do that to appeal to the lingo of his
> expected audience. But I have no idea what an instantaneous value
> versus a non-instantaneous value could possibly be unless domains that
> may appear and disappear, or grow and shrink are allowed (which I
> wouldn't mind considering, but I don't think Codd had that in mind).

The adjective acknowledges a variable can have only one value at any given time, but may never have the same value at any two distinct times.

> For database purposes, when Codd's information principle and the
> closed-world assumption are followed I also fail to see the need for a
> word like "state". It only encourages people to waste time imagining
> some difference between state and value when there is none.

The words separate concerns--much like partial differential equations do. "State" in a dynamic system identifies those parts one can describe or analyze without reference to time. One will generally describe a given state as some value.

It is an important concept to understand.

>>>> I think that if a transaction contains more than one operation, then 
>>>> the order in which each operation is evaluated is critical. 2 + 3 * 
>>>> 5 = 17, not 25.
>>>>
>>>> After the following transaction,
>>>>
>>>> UPDATE r SET x = x + 5 WHERE k = 22,
>>>> UPDATE r SET x = x * 4 WHERE k = 22
>>>> ...
>>>
>>> If all I wanted to do was to add 5 to x and then multiply by 4, I 
>>> would expect my programming environment to give a single statement to 
>>> the dbms, not two.
>>
>> Perhaps, but the updates above are pretty simple, how would you deal 
>> with a transaction consisting of multple updates where the tuples 
>> targeted by each overlap?
>> ...

I would expect the optimizer to simpify the above to:

UPDATE r set x = x * 4 WHERE k = 22

and to eliminate the dead code. Most compilers I use warn when eliminating dead code. Selzer is unable to step out of the comfort zone he learned from more primitive languages.

>>>> Is the result (x + 5) * 4 or (x * 4) + 5?  Or is it x * 4, which is 
>>>> what D&D's multiple assignment would produce?
>>>> ...
>>>
>>> I'm not in favour of encouraging the complexity that multiple 
>>> assignment requires a programmer to be aware of.  (I'm not even in 
>>> favour of assignment to mutable variables.  I realize most 
>>> programmers are used to them and expect them to be supported, but I 
>>> don't care.)
>>
>> I'm not sure what you mean by "mutable variables."
>> ...

>>>> Do you limit a transaction so that only one transformation can occur 
>>>> per relation? Per tuple? Per attribute value?
>>>> ...
>>>
>>> Any concept of a database that has two different values at the same 
>>> time is beyond me.
>>
>> Who said anything about the database having two different values at 
>> the same time?  The question involves a group of modifications to a 
>> database.  The database wouldn't take on the new value until the 
>> entire transaction completed.
>> ...

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.

>>>> Should all constraints be checked after each operation?  Only some?  
>>>> Or should they all be deferred until the end?  I mention this 
>>>> because the result of one operation may leave the database in an 
>>>> inconsistent state, making any subsequent operations suspect.
>>>> ...
>>>
>>> Any dbms that allows a programmer to introduce an inconsistency 
>>> should be recalled.
>>
>> Transitory inconsistencies can occur, so long as they're resolved by 
>> the time that a transaction completes.  A transaction executes in 
>> isolation, but the results of each operation in a transaction could be 
>> made visible to subsequent operations within the same transaction.
>> ...

I am not certain Codd ever suggested deferring constraints. Do you have a reference? Received on Sat Apr 21 2007 - 02:57:34 CEST