After some more reading and considering your feedback, I'm still
somewhat confused about this issue.
1. Should the choice of surrogate/natural primary keys be done across an
entire database, or does it make more sense to do it on a per-table
basis? I reckon one could do it on a per-table basis, but its direct
relationships would influence the choice.
2. If we do find a suitable natural primary key for a table, but it
turns out to be a composite one, how can such a key be referred to in
another table? Say we have:
CREATE TABLE t1 (
PRIMARY KEY (c1, c2)
and I want to create a table t2 which needs to refer to the composite
primary key of t1. Should one create 2 columns in t2 that REFERENCE c1
and c2? If so, this seems very cumbersome and I'm tempted to create a
surrogate key in t1 just to be able to refer to it more efficiently. Is
this something we should be considering when choosing natural
vs. surrogate keys? Thanks again.
In response to
pgsql-sql by date
|Next:||From: Scott Marlowe||Date: 2008-09-17 02:34:51|
|Subject: Re: surrogate vs natural primary keys|
|Previous:||From: Richard Broersma||Date: 2008-09-16 15:30:55|
|Subject: Re: a simple transform|