Re: The Practical Benefits of the Relational Model

In article <aojehe$v0o$1_at_sp15at20.hursley.ibm.com>, Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
>"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message
>news:3DAC627B.813F603C_at_atbusiness.com...
>>
>> What do you have in mind for replacing the functionality of transactions?
>
>Multiple assignment, or more correctly dbvar assignment.
>
>(dbvar = [the] database variable)
>
>Plus the use of local/temporary/database relvars to allow sets of data can
>be built up over time, then be added to the 'main' database in one single
>multiple assignment.

That means an optimistic locking protocol. That is not always what you want.

>But do note that I did not say you don't need transactions under the
>covers, of course we do. Just that database *users* should not be exposed
>to such damaging complexity.

It's not the transaction concept itself that is complex. In theory all the user needs to know is that the transaction begins at some point, ends at some point and sometimes the user or the database can decide to undo everything that was done since the beginning of the transaction. The "damaging" complexity rears its ugly head when you start talking about implementations in practice that do not offer full serializability or explicit locking. But these are in some sense implementation issues. That doesn't mean they are unimportant (on the contrary) but it does mean that it is not the theoretical model that should be changed.

• Jan Hidders