Re: delete cascade

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:HehUh.75979$DE1.32744_at_pd7urf2no...
>I sometimes wonder why the above noun used in place of an adjective is
>needed. When the table/relation definition of a line item references an
>invoice number can it mean anything other than that the line item doesn't
>exist unless the invoice exists? Ie., why shouldn't delete always mean
>so-called "cascade"?
>

You might want to look up the difference between composition and aggregation in your favorite UML reference.

Personally, I avoid using referential actions whenever possible--mainly because they increase the probability that a deadlock will occur, unless of course you add code to obtain locks beforehand in the correct order. It's very easy to forget to add that code since deadlocks are usually rare. Out of sight, out of mind: greater potential for bugs. It's also easier to come back to a procedure and figure out what it does if everything in the database that may be touched by that procedure is accessed directly within it. Again, out of sight, out of mind: greater potential for bugs. Another issue is that in some systems there can only be one cascade path between tables in a database. This leads to inconsistent code: along one path you allow the system to handle it; along another the application must. It should be apparent that inconsistent code can also increase the risk for bugs.

> (just trying to keep Marshall interested.)
>
> p
Received on Sun Apr 15 2007 - 13:41:21 CEST