> 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
