Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Artificial Primary keys

Re: Artificial Primary keys

From: Michael Russell <mrussell_at_beeb.net>
Date: 24 Jan 2002 06:24:30 -0800
Message-ID: <c69419da.0201240624.62e1ed29@posting.google.com>


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 - 08:24:30 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US