Re: cdt glossary 0.1.1 [Transaction]

Brian Selzer wrote:
> "paul c" <toledobythesea_at_oohay.ac> wrote in message
> news:x6SVh.98742$DE1.19705_at_pd7urf2no...
>

>>mAsterdam wrote:
>>
>>>paul c wrote:

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

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

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

Any concept of a database that has two different values at the same time is beyond me.

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

So what? (Most of IT is mistaken. People usually prefer to re-invent old wheels.)

p Received on Fri Apr 20 2007 - 15:22:07 CEST