> 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, ea
> >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
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 act
> 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
