Hi,

> I disagree strongly. inter-row dependances are *not* necessarily a
> sign of poor design. PK's / FK's are an example. You *cannot* insert
> two rows with a PK of 1, that's inter-row dependancy.
>
> I am only suggesting dirty-read be used for check constraints (and
> possibly read-only exception-raising triggers). I don't see how this
> breaks atomicity any more that the operation of Unique Indexes
> (including PK's) which do this anyway.
>
> A unique index can see values in other transactions that havent been
> committed. Period.
>
> According to the quote from Ann (peace be upon her, grin) she also
> believes check constraints should operate in the system transaction
> (is my jargon right? Basically exhibit consistent behaviour with
> indexes, yeah?)

Well, that depends. If it's an "immediate" constraint (like all constraints
in Firebird), then perhaps "yes", it should be in the system transaction.

However, if it's a deferred constraint, then it shouldn't, cause these
will only be enforced upon COMMIT.

Then again, Uniques might be useful deferred as well. For example,
one cannot do this:

CREATE TABLE mytable
(
INTCOL INTEGER NOT NULL PRIMARY KEY
)
COMMIT;
INSERT INTO mytable VALUES (1);
INSERT INTO mytable VALUES (2);
INSERT INTO mytable VALUES (3);
COMMIT;

UPDATE mytable SET intcol = intcol + 1;

While the constraint itself - after all rows have been updated - is
perfectly valid.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com