Re: Ordering dependency problem

From: Qingqing <zhouqingqing_at_excite.com>
Date: 18 Jan 2002 17:39:28 -0800
Message-ID: <cee59be7.0201181739.28ad5a89_at_posting.google.com>


>paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote in message >news:<57da7b56.0201172145.5c53a45b_at_posting.google.com>...
> 71062.1056_at_compuserve.com (--CELKO--) wrote in message >news:<c0d87ec0.0201171044.656f8b4_at_posting.google.com>...
> > I think this is the answer you wanted.
>
> It is a fine answer, Joe. Though I'm note sure that it is quite the answer
> the original poster was asking for. :-)
> My advice is to look up "Halloween Problem", which is a similar example of
>
> Anyway, I hope this contributes something.
>
> KR
>
> Pb

Thanks for inform me the "Halloween problem". I just find out some information about this problem. The origin of this problem is in [1] and there are some different versions. For example, one version is about the "insert", i.e., "insert row after each row in the table".

As Paul pointed out, in existing research/commercial dbms, SQL engine treats it very different. For example, Sybase adaptive server use the similiar way as postgres and that may account for why dbms mandately requires a unique key in the cursor if you use it for update. System R tries to avoid using index if you want to do update for an indexed column. Several months ago, Microsoft SQL server 2000 publish 2 patches for this problem (Q285870, Q294860).

Till now, we have several seem easy but hard problem for dbms engine, "Halloween update", "Halloween insert" , "Halloween delete"(It is easy to define one), "Anti-Halloween update"(Stonebraker's problem since it is lost update while Halloween abc redundant update).

Steal from Paul's sentence, "I hope this add 'gas' to the fire".

Thanks,

Qingqing

[1] Tandem Database Group, "NonStop SQL, A Distributed, High-Performance, High-Reliability Implementation of SQL," High Performance Transaction Systems, Springer Verlag Lecture Notes in Computer Science 359,1989. Received on Sat Jan 19 2002 - 02:39:28 CET

Original text of this message