Re: The Practical Benefits of the Relational Model

From: Jan.Hidders <hidders_at_hcoss.uia.ac.be>
Date: 22 Oct 2002 23:56:02 +0200
Message-ID: <3db5c972$1_at_news.uia.ac.be>


In article <ap401m$1lra$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:3db54bbc$1_at_news.uia.ac.be...
>>> 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.
>
>What need? Unless we are talking to an system external to the database, I see
>no need for transactions and indeed I see them as harmful. If you could give
>me an example where you believe they are *required* within the users concept
>of the database, please do let me know.

If you have a shared budget that you buy the stocks from then the actions of (1) reading the current budget and (2) writing the new budget, should not allow reads and writes of other transactions between them. It's the classical example of a concurrency problem.

  • Jan Hidders
Received on Tue Oct 22 2002 - 23:56:02 CEST

Original text of this message