Re: Question on Primary Keys

In article <8sera4$888$1_at_nnrp1.deja.com>,   Jan Lenders <J.Lenders_at_Betuwe.net> wrote:
> There are database "gurus" who claim that you should never ever use
> class attributes as primary key.
> Instead you add a DBMS-generated primary key value column to each and
> every table. They even claim that these keys should be unique within
> the database; if a Client_Num value 12345 exists, you should not use
> Order_Num 12345.
> The reason was that primary key values may never change (agree) and
> that an object might become of a different class sometime (disagree;
> I've never seen Clients who became an Order).

I'm certainly not a database guru, but I have been -- like many people involved in real-world applications -- severely bitten by legacy applications designed to use 'meaningful' keys. (By legacy application I mean one that was designed by someone else before I got there.) These worst one was product codes which were actually marketing mnemonics, and therefore all had to be changed when the marketing manager came up with a new strategy -- there were practical reasons why that approach would have made sense in the late eighties, but by the mid-nineties the technology was certainly there to provide a better solution.

Conversely, I did once design a venue booking system in which the primary key was a composite of year, week, day, period and venue -- the reason for putting all that info into the key was that we could then satisfy many queries directly from the indexes without even needing to access the primary records.

There are almost always exceptions to absolute rules, but I would need to see a very good justification for using a "meaningful" key.

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Tue Oct 17 2000 - 02:15:21 CEST