Re: Design problem : using the same primary keys for inherited objects.
От | David Pradier |
---|---|
Тема | Re: Design problem : using the same primary keys for inherited objects. |
Дата | |
Msg-id | 20051017135605.GD19930@clarisys.fr обсуждение исходный текст |
Ответ на | Re: Design problem : using the same primary keys for inherited (Daryl Richter <daryl@brandywine.com>) |
Список | pgsql-sql |
> >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. > > It *is* a bad design. You should not do this. After all, how is that > any different than this? > CREATE TABLE actor_person ( > id_actor serial PRIMARY KEY, > arg1 type1, > arg2 type2 > arg3 type3, > arg4 type4 > ) > Furthermore, inheritance is almost certainly the wrong relationship type > here. Normally, Actor would be a Role that a Person would be playing: Oups, I've made a vocabulary mistake. 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, etc... Furthermore, 'person' inherits from 'actor', and some other tables inherits from 'person' : user, physician, customer, etc... Do you continue to think that inheritance is the wrong relationship type here ? > It *is* a bad design. You should not do this. After all, how is that > any different than this? Well, not every line of actor are in laboratory, as some are in person, and in some moreother tables. So, it is different, isn't it ? -- David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source
В списке pgsql-sql по дате отправления: