Re: cdt glossary 0.1.1 [Transaction]
Date: Fri, 20 Apr 2007 13:44:20 GMT
Message-ID: <Us3Wh.26319$PV3.269358_at_ursa-nb00s0.nbnet.nb.ca>
paul c 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.
> 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.
> So what? (Most of IT is mistaken. People usually prefer to re-invent
> old wheels.)
Indeed. Received on Fri Apr 20 2007 - 15:44:20 CEST