Re: Phantom Inserts

And...[having real problems with this thread]

>
>>
>>BTW, how important is the protection against phantom inserts anyway?
>>It doesn't seem common in applications that I have seen.
>
>I don't think that I've ever had to worry about it in any application
>that I've written. Doing the same select twice in a row in the same
>transaction would be so obviously inefficient that I would try to
>design around it as a matter of course.

Bruce, what has been portrayed in this thread is a very primitive example of the phantom update problem. The example of a select paired with insert/select/update is good, but must be extended. If a database product supports concurrent operations and also supplies database level referential integrity ... something most database designers want...the phantom update problem comes into play. Although what you state is true for the particular [or many] application [s] view running within the database...this is *not* true if in the referential integrity area, since you don't know these rules. Also these rules can end up with very complex relationships that, although may be broken down into the primitives represented in this thread and text book chapters on the subject, are not intuitive to application programmers building individual applications in a concurrent database environment.

Cheers,

-Jay Feenan

• Jay Feenan ***
• Oracle Rdb Engineering ***
• ***
• opinions expressed here are solely my own and not those of my ***
• employer. ***
• ***

  ---