Date: Mon, 17 Oct 2005 16:03:27 +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: <20051017140327.GE19930@clarisys.fr>
References: <20051014124334.GC19930@clarisys.fr>
	<BAY103-F36CD330B47F463E9DFAFC2B57D0@phx.gbl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BAY103-F36CD330B47F463E9DFAFC2B57D0@phx.gbl>
User-Agent: Mutt/1.5.9i

> That is perfectly valid. Only, I would argue that an actor is a person.

Oups, i really made a vocabulary mistake here.
Let me paste what i wrote some minutes earlier to Daryl :

----
By 'actor', I meant "somebody who does something". Lots of tables
inherits
from 'actor' in our current design, each of these being a "job" :
laboratory, delivering company, person, etc...
Furthermore, 'person' inherits from 'actor' and some other tables
inherits from 'person' : user, physician, customer, etc...
----

> What I was offering was dealing with issues where more then one actor could 
> be the same person. Given your design, a person could only be one actor. If 
> that is true, no more discussion is needed. If that is not true, then one 
> way to deal with that is to make compound primary keys in your actor table.
> table person (
> person_id serial primary key,
> name varchar(20));
> table actor(
> person_id foreign key references person,
> role varchar(20),
> primary key ( person_id, role )
> );
> would then allow a person to be more then on actor based on role.

It is specified that not two laboratories could be the same actor, for
example.
That's why i think having a primary key referencing another primary key
could technically work, but well, it seems to me BAD to mix two primary
keys together.
I'm still wondering...

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