Data integrity is orthogonal to stored procedures and triggers
Depends on how you define data integrity. If I have a banking application where it should be impossible to update the value of the balance column of the current_account table without there being an appropriate entry in the debit or credit tables I would call it a data integrity issue, and enforcing it with stored procedures and/or triggers would seem a sensible option.
The table doesn't have a behavior that is associated with it. If anything, the behavior is associated with the action that triggers it, not the table the action was performed on.
I think I'll just have to say to-may-to / to-mah-to on this one. As far as I'm concerned when I do something like:
CREATE OR REPLACE TRIGGER enforce_business_rules AFTER UPDATE ON current_account ... etc ...
I'm doing something to the current_account table. YMMV :-)
In reply to Re^3: OO concepts and relational databases
by adrianh
in thread OO concepts and relational databases
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |