<snip>
> I think it's a good idea in any case because DB support does not give you
> the control over this behaviour. You can only define it when you create the
> table. If you, however, use programmatic implementation you explicitly
> specify whether you want to delete the record only if it has no children
> or delete any children if there are. An example would be some financial app
> where a Clerk would only be able to delete an empty bill (created by
> mistake) while a Supervisor would be able to delete any bill whether empty
> or not (do not critisize the example).
In your example, before a Clerk is allowed to delete a bill a check will be run if
the bill is empty before the action is performed (no cascading necessary here).
If a Supervisor deletes the bill you want all items on the bill to be deleted as
well - ON DELETE CASCADE.
It actually reduces programmer error because a programmer does not have to
remember do call doDeleteWithCascade instead of doDelete. Without ON DELETE
CASCADE you need to make sure that your action is part of an atomic transaction
(another place for programmer error) whereas with it you needn't worry. Both are
reasons for you to be more certain of the your database integrity. Less code; Less
bugs :-)
:-) Aren't you trying to write code for something that is already supported by the
RDBMS :-)
~ Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
