Re: Artificial Primary keys

nsouto_at_optushome.com.au.nospam (Nuno Souto) wrote in message news:<3c4ebac6.7497784_at_news-vip.optusnet.com.au>...
>
> This happens mostly because no one is perfect like a computer, and
> data entry errors are made. And people need to be able to change an
> existing id/stdate without having to delete/re-create all info for an
> employee. Which is what they'd need to do if we made id+stdate the
> PK.
>
Nounu,
The point about needing to change the PK is taken; don't you think this can be handled by cascading the changes to all the foreign keys? Or have I misunderstood "cascading"? (As far as these "Assignments" are concerned, there are over-riding business rules prohibiting changes to PK, once their status moves from "Planned" to "Actual").

I've no violent objection to surrogate keys; they do make me wonder if they result from the temptation to second-guess the server-software. What I mean is, perhaps we IT people bring forward some old techniques from flat-file design, when lack of disk-space/memory/speed meant tricks with data were quite accepted and indeed expected. Maybe, as "old" techniques, they don't apply; haven't servers been written by 3rd/4th generation designers who know, or have inherited knowledge of, the business of optimisation quite thoroughly, anyway?

Regards and thanks for your reply,

Michael Received on Thu Jan 24 2002 - 15:24:30 CET