From: | Ron Peterson <rpeterson(at)yellowbank(dot)com> |
---|---|
To: | "Richard Rowell ;" <rrowell(at)spamfree(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Primary key question |
Date: | 2000-07-05 18:56:32 |
Message-ID: | 396384E0.A3A9B908@yellowbank.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Richard Rowell wrote:
>
> I'm creating a database with 20 tables or so. I have come to the
> table that will likely tie many of these tables together, that is
> every single field in this table will be a foriegn key. My question
> is, rather then include all of the fields into the primary key of this
> table, and therefore include all of these fields into any table that
> will reference this one, would it be politically correct to just give
> each entry an integer as a primary key and scan for dupes in a
> trigger? It sure seems like it would cut down on the complexity of
> the whole thing...
If I understand correctly, it sounds like what you want to do is
establish a UNIQUE constraint on your foreign keys, and add a sequenced
integer to be the primary key for this table. E.G. -
CREATE TABLE test (
fkey1 INTEGER REFERENCES ...,
fkey2 INTEGER REFERENCES ...,
id SERIAL PRIMARY KEY,
UNIQUE(fkey1,fkey2)
);
________________________
Ron Peterson
rpeterson(at)yellowbank(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-07-05 18:57:57 | Re: proposed improvements to PostgreSQL license |
Previous Message | The Hermit Hacker | 2000-07-05 18:49:59 | Re: PostgreSQL 7.1 |