X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 51D42D7003 for ; Mon, 17 Oct 2005 10:55:26 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 93849-10 for ; Mon, 17 Oct 2005 13:55:21 +0000 (GMT) Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by svr1.postgresql.org (Postfix) with ESMTP id CB82BD711C for ; Mon, 17 Oct 2005 10:55:23 -0300 (ADT) Received: from jobmare.clarisys.lan (claridsl512.net1.nerim.net [213.41.148.137]) by kraid.nerim.net (Postfix) with ESMTP id E539D40F95; Mon, 17 Oct 2005 15:55:25 +0200 (CEST) Received: from day by jobmare.clarisys.lan with local (Exim 4.52) id 1ERVTB-0006VH-Vh; Mon, 17 Oct 2005 15:56:06 +0200 Date: Mon, 17 Oct 2005 15:56:05 +0200 From: David Pradier To: Daryl Richter Cc: Russell Simpkins , pgsql-sql@postgresql.org Subject: Re: Design problem : using the same primary keys for inherited objects. Message-ID: <20051017135605.GD19930@clarisys.fr> References: <20051014091829.GB19930@clarisys.fr> <20051014124334.GC19930@clarisys.fr> <434FC756.90901@brandywine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434FC756.90901@brandywine.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 required=5 tests=[FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200510/181 X-Sequence-Number: 23034 > >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