From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | David Pradier <david(dot)pradier(at)clarisys(dot)fr> |
Cc: | codeWarrior <gpatnude(at)hotmail(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Design problemi : using the same primary keys for inherited |
Date: | 2005-10-17 16:57:52 |
Message-ID: | 4353D810.2050606@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
David Pradier wrote:
> Well yes, i find your system very interesting and will maybe use it as
> solution for another problem we have ( :-) ), but i fail to see where
> it makes use of a primary key referencing another primary key ?
As regards the issue of one primary-key referencing another, I can't see
any problem. You want 0 or 1 references from table B to any row in table
A - this does that without any fuss or complication.
A primary key is a value (or set of values) like any other. It is unique
over any one table, but nothing says it can't be the same as a value in
some other table.
The other way would be something like:
CREATE TABLE A (
id serial not null unique,
aval text,
primary key (id)
);
CREATE TABLE B (
id serial not null unique,
aref int4 not null unique references A,
bval text,
primary key (id)
);
So - in table B we now have two candidate keys (id, aref) and above I've
chosen "id" as the primary-key. But I can eliminate "id" completely and
not lose any of the meaning of table "B" - which tells me that I was
wrong to think the rest of the table was dependent on "id". So, I must
have been wrong in making "id" a primary-key and since it has no meaning
of its own, I can eliminate it.
CREATE TABLE B (
aref int4 not null unique references A,
bval text,
primary key (aref)
);
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Adriana Marcela Aguirre | 2005-10-18 14:26:59 | Consulta! |
Previous Message | David Pradier | 2005-10-17 14:13:53 | Re: Design problemi : using the same primary keys for inherited objects. |