Re: The Practical Benefits of the Relational Model

In article <ap6adp$1s8s$1_at_sp15at20.hursley.ibm.com>, Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote: <
>Yes that is the classical example but it does not show that transactions are
>*required*. I'm saying that problem is more flexibly solved by database design
>rather than by transactions. I guess I could concede that it makes database
>design more difficult, but I see that as a price that we need to pay to free
>us from some users abusing transactions.

I think you still have to show that they always can. That's rather important because your suggestion makes using the database a lot harder. Moreover, what you suggest can in fact be implemented if you have transactions. So it seems that you are only making things more complicated for no apparent good reason.

>one of many possible db designs would be
>
>STOCK (S StockSymbol, Price Money)
>BUDGET(M Money)
>BUDGET_LOCK(L Boolean, U User)
>
>check(NOT (M <> M' AND L AND U <> USER()) )
>check(NOT (L' AND NOT L AND U <> U') )
>check(NOT (L' AND M <> M' AND L) )
>check(NOT (L <> L' AND U <> USER()) )

Syntax error. These are not all tuple constraints so we need some quantifiers here. Yes, that's nitpicking but I think it is important to see how complicated this will actually get.

Anyway, between the checking of the constraints (which require reading information from the database) and the actual update you don't want other operations in between. For example, between checking that you actualy can get the lock and actually getting it, it should not be possible that another user sneaks in between those operations and also gets the lock. So you still need the notion of transaction here. And checking dynamic constraints isn't really very cheap either.

• Jan Hidders