[AccessD] Re: The Great Primary Debate

John,

Great argument for surrogate keys.  Since the user has no control of them, 
you never have to do a cascade update.  You simply make the change to the 
business keys and nothing is cascaded.

A simple example is the way department names change within a business 
organization.  By using department id as the surrogate key and department 
name as the business key, you can maintain the names as they change and 
never need to cascade that change through a bunch of tables.

Robert

At 11:44 AM 6/3/2004 -0500, you wrote:
>Date: Thu, 3 Jun 2004 12:26:46 -0400
>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Subject: RE: [AccessD] OT: The Great Primary Debate
>To: "'Access Developers discussion and problem solving'"
>         <accessd at databaseadvisors.com>
>Message-ID: <000601c44987$90bd3c70$7e01a8c0 at colbyws>
>Content-Type: text/plain;       charset="us-ascii"
>
>It has more to do with having fields from other entities which is a
>no-no in relational design.  Remember that these other entity attributes
>nave to be updated should they change.  What is changing them?
>
>John W. Colby
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
>Foust
>Sent: Thursday, June 03, 2004 11:32 AM
>To: Access Developers discussion and problem solving
>Subject: RE: [AccessD] OT: The Great Primary Debate
>
>
>In the strictest sense that may be true because you now have more than
>one unique key on the table, but since "candidate" keys are acceptable
>in relational design, I wouldn't worry about that myself.  And if you
>have a single field unique key, that is always preferable to a compound
>unique key as a PK, since it is easier to manage and doesn't require
>inserting multiple FK fields into another table.
>
>Charlotte Foust