Re: cdt glossary 0.1.1 [Transaction]

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:2kdWh.26527$PV3.272558_at_ursa-nb00s0.nbnet.nb.ca...
> 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.
>
>
> 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 don't see how a transaction can involve more than one "update". As Jim
>> Gray might have said, one can't marry two people at once.
>
> 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.
>

That's a pretty large leap, but it supports my original argument. D&D's multiple assignment relies on the order of the operations in the submitted statement, but if a transaction is a *set* of operations, then there's no way to determine which of the updates to eliminate! As a result,

UPDATE r set x = x + 5 WHERE k = 22

could be considered just as valid as

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

>
>>>>> 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."
>>> ...
>>
>> Maybe that's an unconventional term. I mean a variable that can be
>> assigned to twice in whatever programming unit we define to constitute a
>> transaction.
>
>
>>>>> 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.
>>> ...
>>
>> You did, when you said (above) that "one transformation" is a "limit".
>
> 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.
>

That's a pretty bold, and quite frankly, naive statement. Transactions are not only used to guarantee the consistency of updates, they're also used to guarantee the consistency of queries. It is also often quite beneficial to use intermediate results in subsequent operations. The result of one operation may eliminate the need for or alter the target of another. Why reinvent the wheel in the client?

As I said earlier, D&D obviously acknowledge the need for separate transaction boundaries, or they wouldn't have included begin transaction/commit transaction in their description of Tutorial D.

>
>>>>> 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'll repeat - any dbms that allows a programmer to introduce an
>> inconsistency, transitory or otherwise, should be recalled. I'm sure
>> that given the physical speed of the consumer machines that superceded
>> the mainframes of his day, had they been available in 1969, Codd would
>> not have suggested that the correction of inconsistencies could be
>> postponed.
>>
>> p
>
> I am not certain Codd ever suggested deferring constraints. Do you have a
> reference?
Received on Sat Apr 21 2007 - 16:25:47 CEST