Re: Surrogate VS natural keys

From: Rich Shepard <rshepard(at)appl-ecosys(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Surrogate VS natural keys
Date: 2007-06-20 15:39:23
Message-ID: Pine.LNX.4.64.0706200837130.22882@salmo.appl-ecosys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 20 Jun 2007, brian wrote:

> The former uses a primary key across both columns to enforce a unique
> constraint. In the latter, you have a seperate ID column, which does not
> enforce that constraint. And you have to ask yourself if you'll ever be
> referencing that ID column for anything at all. I doubt i ever would.
> Generally, you'd be using this to relate rows from a more generalised
> table using either the club ID or the user ID. I can't see how having a
> seperate serial ID column would be useful for any kind of select.

Also, the reason for a third, M-M, table is to relate multiple players and
multiple clubs. If you think of the logic involved, your third table has
only one row for each player-club combination. Therefore, each row is unique
by definition and a surrogate key adds no value.

Rich

--
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2007-06-20 15:58:46 Re: Surrogate VS natural keys
Previous Message marcelo Cortez 2007-06-20 15:08:46 Re: PostgreSQL Installer for Windows x64