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
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 |