Re: The Practical Benefits of the Relational Model
Date: 22 Oct 2002 14:59:40 +0200
Message-ID: <3db54bbc$1_at_news.uia.ac.be>
In article <ap3edp$13j2$1_at_sp15at20.hursley.ibm.com>,
Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
>"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message
>news:3db515aa$1_at_news.uia.ac.be...
>>
>> 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.
I don't think the information principle is relevant here. I know you already mentioned auditing as an example, but I really don't think that is a good example. It depends on what you call "the information". I would say that the logs do not belong to that. If you want that then it should be explicitly modeled in your tables and then your boundaries of your transactions would change because you want intermediate results also to be committed to those tables.
>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.
Sure. If you don't need transactions, then don't use them. But in all the cases you mentioned there is the need to declare a set of 2 or more reads and updates as atomic, viz. with the transfer of money.
- Jan Hidders