>>RI is purely a function of relationships between entities in a database.. not the validity of the data held within the columns of non-RI columns.
>
>I disagree. Here is a biz rule that expresses referential integrity.
>
>"When a salesman is fired, move all of his customers to his manager". This prevents orphan customer records. This rule may change over time... such as
>"When a salesman is fired, move all of his customers to the newest salesperson".


Great example....

Here, though, a biz rule lends it self to rather than replaces RI, consider:

Create Or Replace Trigger tr_ReassignAccounts(p_Account, p_newAssignee) As

BLAH, BLAH, BLAH

Update this where that

--etc.

End;

The point I argue is that the RI constraints of the database, whether enforced by triggers, procs called within triggers, etc should be independent of the foibles of the person or process trying to affect data within the database.

A well concieved RI scheme would prevent an illegal assignment in your example (Or automatically reassign accounts based on some rule.) Does this remove burden from the developer... CERTAINLY NOT... it says simply that whomever decides to do 'some-thing' to this set of data must live within a given set of rules.

I don't like the idea of coding to exeptions; however, building in rules within the data layer to ensure that ALL applications, clients, etc that have the ability to change data must live by a set of rules that ensure the integrity of an entire database must be enforced by the least common denominator... the database itself.

Mark