Re: insert different from union?

"Bob Badour" <bbadour_at_golden.net> wrote in message news:erednbkUIcjoAYjdRVn-vA_at_golden.net...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
[snip]
> > 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).
>
> I think we are saying the same thing.

Mostly, but again I think I'm being stronger. Rather than saying 'there is work to do' to understand these things fully which may or may not result in them being workable, I'm optioning that they *are not* workable.

> If we are to have triggered
> procedures, we need to start with assignment as a trigger and work from
> there.

Actually, I don't actually think triggered procedures are a good idea at all, never mind the obvous difficuties of defining I/U/D triggered versions.

> The way SQL works (and possibly tutorial D too) puts the cart before
> the horse.

Agreed for SQL, tutorial D is dangously close in places to assuming that there is such a thing in general as a 'row update'.

Going back to my example,

If R equals { <a:1, b:1>, <a2, b2> }
and has two candidate keys {a} and {b}
and S equals { <a2, b1>, <a1, b2> }

Then

R := S

Leaves us with a tricky question about which, if any rows got 'updated'. I'm not sure that there is any usefull general answer to that question.

Of course I could be wrong, and that some consistent method of identifying 'updated rows' would be usefull. But, it all just smacks of row level thinking in my opinion.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Jan 27 2004 - 14:14:27 CET