Re: Surrogate VS natural keys - Mailing list pgsql-general

From Rich Shepard
Subject Re: Surrogate VS natural keys
Date
Msg-id Pine.LNX.4.64.0706200837130.22882@salmo.appl-ecosys.com
Whole thread Raw
In response to Re: Surrogate VS natural keys  (brian <brian@zijn-digital.com>)
Responses Re: Surrogate VS natural keys  (Martijn van Oosterhout <kleptog@svana.org>)
List 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

pgsql-general by date:

Previous
From: marcelo Cortez
Date:
Subject: Re: PostgreSQL Installer for Windows x64
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Surrogate VS natural keys