Re: Can these constraint be implemented in an RDBMS ?

After a long battle with technology, "ben brugman" <ben_at_niethier.nl>, an earthling, wrote:
> Reducing the example to 1-2 tables makes it less complex and
> that was one of the points made. A situation to complex to
> implement in an existing RDBMS.

And this also expresses one of the vital principles of use of "scientific method;" if you are trying to demonstrate some effect, it is highly preferable to reduce the situation to being as simple as possible where the phenomenon may be observed.

A recent discussion of deadlocks in MySQL was nicely demonstrated by the following quite simple example that leads to a deadlock.

> use test;
> drop table t;
> create table t(id int, x int) type=innodb;
> insert into t values(1,50);
> insert into t values(2,100);
> commit;
>
>
> T1:
> use test;
> set transaction isolation level serializable;
> set autocommit=0;
> update t set x=-1 where id=1;
>
>
> T2:
> use test;
> set transaction isolation level serializable;
> set autocommit=0;
> update t set x=-1 where id=2;
>
> -- T2 hangs despite trying to update a different row.

A coworker has similarly pointed out the flaws in a database replication system based on a _simple_ set of three database updates that demonstrate how it falls into the trap of a particular flaw.

You can't get away with the nonsense of baffling would-be users with a _purported_ fix if they actually have a simple case that shows why the system is broken. (And which might _still_ be broken, despite claims of a "remedy.")

-- 
output = reverse("gro.mca" "_at_" "enworbbc")
http://www.ntlug.org/~cbbrowne/oses.html
Rules of the Evil Overlord  #190. "If my mad scientist/wizard tells me
he  has  almost perfected  my  Superweapon  but  it still  needs  more
testing,  I will  wait for  him to  complete the  tests.  No  one ever
conquered the world using a beta version."
<http://www.eviloverlord.com/>