Re: delete cascade

Bob Badour wrote:
> ...
> Paul, I believe you are confusing two things. Whether the delete
> cascades has no bearing on the logic for expressing the condition. The
> <AND> and <OR> expression a la TTM would be the same in either case.
>
> The normal effect of a constraint is simply to block any inconsistent
> update. You gave an english phrase suggesting all foreign keys should
> cascade deletes, and I gave a similar english phrase suggesting they
> should not. Both are useful.
>
> One must keep in mind a foreign key declaration is a convenient
> shorthand. The plain foreign key declares a constraint and is all
> "what". The "on delete cascade" feature extends the constraint with a
> triggered procedure, which thus combines some "how" with the "what".
>
> More and more, I am liking "on delete" or "on update" less and less. I
> suggest the appropriate place to handle the issue is in the view
> specification. If one wants "on delete cascase", one can present a view
> with the invoice items as an RVA.
> ...

Maybe what I was confusing was what SQL is versus what I think it should be. The latest chatter about transactions reminds me that I could just as well have complained about the difficulty of inserting invoice items before an invoice is inserted.

That is intriguing about RVA's. Do you have in mind entwining the notion of an invoice transaction with a reference constraint by not assigning the rva until it is known (by some program) that all items have been inserted (into some table or other)?

p Received on Sun Apr 22 2007 - 06:17:58 CEST