Date: Fri, 14 Oct 2005 14:43:34 +0200
From: David Pradier <david.pradier@clarisys.fr>
To: Russell Simpkins <russellsimpkins@hotmail.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Design problem : using the same primary keys for inherited
	objects.
Message-ID: <20051014124334.GC19930@clarisys.fr>
References: <20051014091829.GB19930@clarisys.fr>
	<BAY103-DAV1541E0C0650CC9BDA28204B57D0@phx.gbl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BAY103-DAV1541E0C0650CC9BDA28204B57D0@phx.gbl>
User-Agent: Mutt/1.5.9i

> Most of the inheritance i've seen done in databases retain the parent primary as a foreign key and a primary key. That being said, only you and your team can decide if more than one object will extend a base class. If you were doing something more like this
> person -> sweepstakes entry
> to model a sweepsakes entry is a person, and you allow a person to enter a sweepstakes more than once, but to enter a contest the user must provide a unique email address, then you could not just use a foreign key as the primary key in sweepstakes, since the primary key would disallow multiple entries in sweepstakes entry, you would then use a serial data type in both person and sweepstakes along with the foriegn key in sweepstakes from person.
> The answer depends on the need. Hope that helps.

Thanks Russ, but well...
It doesn't help me a lot. Our needs seem to allow that we use an id as
primary key and foreign key at the same time.
What i fear more is that it be against a good database design practice,
because leading to potential problems.

I give a clearer example :

CREATE TABLE actor (
id_actor serial PRIMARY KEY,
arg1 type1,
arg2 type2
)

CREATE TABLE person (
id_person INTEGER PRIMARY KEY REFERENCES actor,
arg3 type3,
arg4 type4
)

Don't you think it is a BAD design ?
If it isn't, well, it will expand my database practices.

David

-- 
David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source