Re: Phantom Inserts
Date: 24 Feb 95 16:36:21 GMT
Message-ID: <3il5gb$jgd_at_jac.zko.dec.com>
In article <793588545snz_at_granby.demon.co.uk>, bh_at_granby.demon.co.uk (Bruce Horrocks) writes... Some hickup in the system...here is a re-reply to this.
[snipped]
>
>Funny how both the responses form Oracle personnel mentioned Rdb
>rather than (original) Oracle.
The reason for these sources...is due to the posting of this in the comp.databases.rdb newsgroup, based on Oracle Rdb (formerly DEC Rdb)
. . .
>
>>
>>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. ***
- ***