From: | "Dan Langille" <dan(at)langille(dot)org> |
---|---|
To: | "Postgres Admin List" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: string PK vs. interger PK |
Date: | 2002-04-15 20:02:44 |
Message-ID: | 20020415200405.9BCD93F28@bast.unixathome.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 15 Apr 2002 at 14:20, Nick Fankhauser wrote:
> As a general rule, a primary key (or any relationship key) should not
> contain a value that means something beyond its use in relating entities.
> The problem is that if a field describes an object, the day may come when
> you want to change the description, but you *never* want to change the
> field that identifies the record and relates it to other records.
FWIW, I would recommend not using business values as a primary key (and by
extension, as a foreign key). Business values are just that: business
values. Sure, put unique constraints on business values if you want.
Just don't make them a primary key or a foreign key.
--
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/ - practical examples
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-15 20:34:10 | Re: Alter/update large tables - VERRRY annoying behaviour! |
Previous Message | Marc Mitchell | 2002-04-15 19:51:38 | Re: string PK vs. interger PK |