Re: TRICKY TRIGGER QUESTION

In article <871932025.4473_at_dejanews.com>, sprajapa_at_fmrco.com writes:
> We have primary key as composite key and value of some of the
> columns will change. Very difficult to prohibit developers and
> users from not changing primary key. And overall, "unique primary
> key" rule is maintained any way.
>
> I like to design in such a way that primary key don't change
> (delete/insert is okay) but then, even in C. J. Date's book, I don't see
> any reference to "primary key change is intrinsically wrong".
>

I didn't bother looking in Date's book but it's wrong to go about changing the primary key for many reasons including the problem that you are seeing. Imagine having a master-detail relationship and changing the master primary key. Now you'll have to go and change the detail rows too. Imagine now having many, many, many detail relations hanging off the master.... does it still make sense to be changing the primary key? No, that's why you add a surrogate key. That's my point.

--
Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p_at_pager.sgi.com
--------------+-----------------+--------------------------------------------
pablo_at_sgi.com ... when mailing me, place "not spam" in the Subject