Re: OO and relation "impedance mismatch"

Kenneth Downs wrote:
> You always want to err on the side of correct data, which leads to
dirty
> reads, which leads to the possibility that you will have spurious
failures.

I'm actually more concerned about spurious successes than spurious failures. I use Oracle, which doesn't even do dirty reads, so I am not sure exactly what would happen with dirty reads in this scenario:

User A> insert into parent (pid) values (123);

User B> insert into child (pid, cid) values (123, 456); -- dirty read sees user A's record and allows the insert

User A> rollback;

User B> commit;
-- User B's child record is now an orphan.

Could that not happen with your trigger-based approach?

> I don't like that anymore than you do, but at the moment my feeling
is that
> it is superior to the collection of problems you get with
fail-on-first.

The only "problem" with fail-on-first is that it may irritate users when (a) they make 2 or more errors on the same insert, and (b) the application fails to catch 2 or more of them. I'd say that that is a less serious problem than constraints that aren't enforced 100% properly, as I believe they can't be using triggers.

Another question: how can you generate the code for your triggers from the data dictionary, when your data dictionary doesn't know about primary keys, unique keys, foreign keys?

Why not (just to please me!) create all the proper, declarative constraints AND generate your triggers from them. That way you can present the errors in the way you like, without (I believe) compromising data integrity. Received on Tue Oct 05 2004 - 20:43:42 CEST