Re: surrogate vs natural primary keys - Mailing list pgsql-sql

From Scott Marlowe
Subject Re: surrogate vs natural primary keys
Date
Msg-id dcc563d10809170745n24f5ae73i7e6ba3ec73743dbc@mail.gmail.com
Whole thread Raw
In response to Re: surrogate vs natural primary keys  (Seb <spluque@gmail.com>)
Responses Re: surrogate vs natural primary keys  ("Richard Broersma" <richard.broersma@gmail.com>)
List pgsql-sql
On Wed, Sep 17, 2008 at 7:20 AM, Seb <spluque@gmail.com> wrote:
> On Tue, 16 Sep 2008 20:34:51 -0600,
> "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>
> [...]
>
>> create table t2 (
>>     d1 varchar(200),
>>     d2 int8,
>>     d3 varchar(1000),
>>     foreign key t2_fk references t1(c1,c2) );
>
> Thanks Scott, I guess you meant:
>
> CREATE TABLE t2 (
>    d1 varchar(200),
>    d2 int8,
>    d3 varchar(1000),
>    PRIMARY KEY (d1, d2)
>    FOREIGN KEY (d1, d2) REFERENCES t1(c1, c2) );
>
> But this makes it difficult to work with t2 because it has 2 fields that
> are the same as in t1.  Isn't it better to just use a surrogate key and
> use a single field in t2, thereby avoiding repeating multiple pieces of
> information?

Yes and no.  If you're gonna hit table t2 a lot by itself, then it's
more efficient to have the data there in t2 and not have to join to t1
to get it.  There are always use cases that go either way in this kind
of situation.


pgsql-sql by date:

Previous
From: Seb
Date:
Subject: Re: surrogate vs natural primary keys
Next
From: "Raphael Bauduin"
Date:
Subject: Re: Trigger Procedure Error: NEW used in query that is not in a rule