Re: Phantom Inserts

In article <793742311snz_at_granby.demon.co.uk>, bh_at_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. ***
• ***

  ---