Subject | Re: Db Design opinions sought - Lookup tables and surrogate PKs |
---|---|
Author | didiergm |
Post date | 2002-07-27T11:36:16Z |
Raul,
I see where you're coming from but... the example is wrong as a
countries lookup table is not cast in stone. a couple of wars or
revolutions ... and countries get created, merged, inveded ... a the
old country code cannot apply anymore, so you'd have to change all
records in all tables where this code applies ...
I'd go for an integer, and use the code only to help users.
I may sound pedantic but I had to go through that in the past...
Hth
Didier
I see where you're coming from but... the example is wrong as a
countries lookup table is not cast in stone. a couple of wars or
revolutions ... and countries get created, merged, inveded ... a the
old country code cannot apply anymore, so you'd have to change all
records in all tables where this code applies ...
I'd go for an integer, and use the code only to help users.
I may sound pedantic but I had to go through that in the past...
Hth
Didier
--- In ib-support@y..., "Raul Chirea" <raul_chirea@l...> wrote:
> Hi,
>
> From: "Frank Ingermann" <frank@f...>
>
> > imho it strongly depends on how the lookups will be used - there's
pro's
> and
> > con's to both approaches:
>
> Yes. For example, it would be amusing (not to say really stupid) to
make a
> "countries" table having "country_code", "country_name" fields and an
> integer "id" as the PK when "country_code" can be used very well as
a PK and
> also it has a meaning.
>
> Raul.