Re: insert different from union?

"Bob Badour" <bbadour_at_golden.net> wrote in message news:d_ednSQFv-Lb5ojd4p2dnA_at_golden.net...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:bv3ntf$rqa$1_at_gazette.almaden.ibm.com...
[sinp]
> > A possibly more interesting question is, should ON INSERT triggers be
> fired
> > when someone does
> >
> > A := A union B
> >
> > ?
> >
> > And then what about on
> >
> > A := B
> >
> > If A equaled { <1, 1>, <2,2> }
> > and B equals { <2,1>}
> >
> > Should we have two DELETE and one INSERT triggers fire, or one DELETE
and
> > one UPDATE. If the latter, which row in A does which trigger fire one?
> >
> > If you say, triggers don't fire on assignment, what about if I do
> >
> > PRE( ( A{candidate key} intersect B{candidate key} ){} = DUM )
> > A := A union B
> >
> > Why should that not fire triggers when the identical
> >
> > INSERT INTO A VALUES B
> >
> > would.
> >
> > Or would it...
>
> If you are trying to make the point that triggered procedures are not yet
> well-understood, I agree. The principle of cautious design suggests
> minimizing their use.

I would be some what stonger and say that triggered procedures (as they are typically understood) are incompatable with the idea that INSERT, UPDATE and DELETE are but shorthands.

Either have I/U/D as primatives and keep your triggered procedures, referential actions and row level transitions constraints, or be brave and drop the lot of them. I say drop 'um all, and revel in a clearer model (and after some work, a more functional model).

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Jan 26 2004 - 22:03:05 CET