Re: Phantom Inserts

In article <793742311snz@granby.demon.co.uk>, bh@granby.demon.co.uk (Bruce Horrocks) writes... Bruce, I disagree with your arguement... Ian's example: >>An example might be: select all salespeople who earned excess profit over >>budget, and calculate bonus amount. Now update all those same salespeople and >>apportion the bonus according to their contribution. The first query processes >>the row set A (with cardinality n) performing an aggregation. The second query >>needs to process the same set A. If a phantom was introduced (a sales person >>who delivered that last minute sale, then the bonus calulation would be wrong >>and the apportionment would be incorrect because the cardinality has changed. > Your arguement: >This example is easily refuted: there would always be a cut-off date, >e.g. the end of the financial period, for the submission of sales >results and the bonus calculation would take place after this. Any >late entries would count against the next financial period and so >couldn't affect the result. > My arguement: Applying it to the above thread of thought. In many business applications that I worked on years ago you are making assumptions which don't apply. When new orders can't be added at point-of-sale. New orders can be added after a sales date. The legal binding date is that on the document. The 'cut off date' doens't work since these would be legal orders, are organized [from this perspective] on the order date and can be inserted into that timeline [selection criteria...from a database perspective]. Your arguement basically states that I have a business rule that prevents one application from inserting into the initial select, thus the second select is 'phantom safe'. Although systems can be taken off-line or certain applications [read-transactions] can be prevented from accessing a concurrently accessed database...and maintain business rules. I'll still maintain that phantom prevention must be maintained within the database system to implement these rules through some database level integrity mechanisms. -Jay Feenan ********************************************************************* *** Jay Feenan *** *** Oracle Rdb Engineering *** *** *** *** opinions expressed here are solely my own and not those of my *** *** employer. *** *** *** *********************************************************************