From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | John McCawley <nospam(at)hardgeus(dot)com>, Scott Ribe <scott_ribe(at)killerbytes(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: IS it a good practice to use SERIAL as Primary Key? |
Date: | 2006-11-28 00:29:44 |
Message-ID: | B2E16C01-4C2A-40C5-A836-606B0E6D7033@seespotcode.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Nov 28, 2006, at 9:02 , Joshua D. Drake wrote:
> On Mon, 2006-11-27 at 17:31 -0600, John McCawley wrote:
>> I promise I'm not trying to be a pain in the butt ;) Do you then use
>> your serial id as your foreign key in other tables, or the
>> firstname/lastname primary key?
>
> Now that is a good question. I would use the id, but that is not
> technically proper :).
If you have both a surrogate key (the serial column) as well as a
natural key (e.g., the (first_name, last_name) composite key), what
difference does it make? You can get to the first_name, last_name
data via a join on the surrogate key.
I'm currently loosely in the surrogate key + natural key camp. One
advantage of this is that if there *is* a change to the natural key,
it can be changed in one table rather than cascading throughout the
database schema.
Michael Glaesemann
grzm seespotcode net
(Can we talk about NULL next? :P)
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2006-11-28 00:37:53 | NULLs ;-) |
Previous Message | Scott Ribe | 2006-11-28 00:22:57 | Re: IS it a good practice to use SERIAL as Primary Key? |