Re: cdt glossary 0.1.1 [Transaction]

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:Us3Wh.26319$PV3.269358_at_ursa-nb00s0.nbnet.nb.ca...
> paul c wrote:
>
>> Brian Selzer wrote:
>>
>>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>>> news:x6SVh.98742$DE1.19705_at_pd7urf2no...
>>>
>>>> mAsterdam wrote:
>>>>
>>>>> paul c wrote:
>>>
>>> [snip]
>>>
>>>> I wasn't suggesting it did. As far as I know, "order of work" is not a
>>>> relational issue, nor is a transaction a relational concept any more
>>>> than invoices are. Wondering why they aren't part of RT is like asking
>>>> why the RM isn't based on a state machine.
>>>
>>> So what would you call something that transforms one database state into
>>> another? In 1970, Codd called them "state-changing transactions."
>>> ...
>>
>> Codd subscribed to the idea of a data sub-language. I think whenever he
>> used terms such as "states" and "transactions", he was talking about a
>> programming environment, not the RM.
>>
>> ...
>>
>>> 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.
>>
>>> 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?
>>> ...
>
> Brian misses a very important point: D&D provide the WITH keyword. If one
> wanted (x + 5) * 4, one could give a name to the (x + 5) expression
> (assuming one did not know how to nest algebraic expressions in the first
> place.)
>
> Thus, with the D&D approach, one can explicitly state whether it should be
> (x + 5) * 4 or x * 4. Selzer clues out on the loss of the ability to
> express x * 4 when depending on implicit information.
>
>
>> 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.)
>>
>>> Do you limit a transaction so that only one transformation can occur per
>>> relation? Per tuple? Per attribute value?
>>> ...
>
> I prefer the D&D approach that doesn't require transactions at all.
> Arbitrarily complex updates are single statements.
>

So why is BEGIN TRANSACTION and COMMIT specified as statements in Tutorial D? Obviously, D&D think they're important, or they wouldn't have been included.

>
>> Any concept of a database that has two different values at the same time
>> is beyond me.
>
> Look! It's a bird! It's a plane! It's a figment of somebody's imagination!
>
>
>>> 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.
>>
>>> If it were possible to convert a group of statements into a single
>>> operation, then there would be no need for order, there would only be
>>> one transformation per relation, per tuple and per attribute value, and
>>> constraints would only need to be checked once. Alas, this capability
>>> is not available in any commercial system that I know of, and even D
>>> doesn't doesn't support it.
>>> ...
>
> Selzer is too stupid to realize that D does support it and supports it
> correctly by requiring explicitness.
>

Wrong again! I suggest you revisit chapter 5 of TTM.

>
>> So what? (Most of IT is mistaken. People usually prefer to re-invent
>> old wheels.)
>
> Indeed.
Received on Fri Apr 20 2007 - 16:01:23 CEST