Re: The Practical Benefits of the Relational Model

"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3db515aa$1_at_news.uia.ac.be...
> In article <ap0iuv$11i0$1_at_sp15at20.hursley.ibm.com>,
> Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
> >
> >Database constraints (often with a temporal component) can be used by users
> >(when allowed by the database design) to create guarantees about whether
> >values just read are still valid. Such a constraint based approach not only
> >exposes all 'locks' as relational data, but also allows different relvars
> >(and sets of relvars) within a database to have different locking
> >'protocols' implemented. It is my position that locking is a database
> >design issue rather than a DBMS 'feature'.
>
> I agree, but to me that means that the DBMS should allow the DBA to choose
> the appropriate locking protocol.

OK, but I like the idea of (or at least the possibility of) of different protocols on different tables in the same database. Also, in the future their won't be enough DBAs to go around.

> However, your suggestion seems to be to
> let all the applications do their own locking.

Well, the *users* do their own locking, but they can use an 'application' to help them interact with the database if they so wish.

> I cannot imagine that you
> really think that this will be easier to understand for the application
> builders then the concept of transaction.

I do think that once a user has understood the relational model, and once they truly subscribe to the Information Principle, then they would naturally see locks as being predicates, and be confused by the whole transaction concept. At the very least, that is my personal experience.

The transaction concept only works well in certain restrictive circumstances. When you buy shares on a stock market, you are not able to lock the price before you buy or sell. On an auction site, locks or lack of them are part of the business rules underlying the dynamics of the auction. The concept of transactions attempts to 'black box' these issues, I think they need to be exposed as part of database design.

> By the way, using predicates/constraints for locks is done in the socalled
> 'predicate locking protocol'. Would that be similar to what you are
> proposing? It's not the easiest of protocols.

The name certainly sounds bang on. I would not be surprised if existing proposals were 'not easy'. Thanks for the link, I'll certainly try to find the time to follow it up.

> If you want to know more about locking and transaction management I can
> recommend the book "Transactional Information Systems" by Gerhard Weikum and
> Gottfried Vossen:
>
> http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-508-8#Contents
>
> I believe they talk in section 8.2 about on predicate locking.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Oct 22 2002 - 13:55:58 CEST