Re: [SQL] Design problemi : using the same primary keys for inherited objects.

[Russell Simpkins]

----- Original Message ----- i've got a strange design question to ask you. It's something I couldn't answer to while feeling confusely it was an absolutely BAD thing to do. For our application, we have developed our own framework which sits on top of PostgreSQL. It uses object programming and implements heritage. Inherited objects use heritage links in the framework and relation links in PostgreSQL (Search me why it doesn't use heritage in PostgreSQL !?). I've got this thing : An object A inherits from an object B, which inherits from a object C, which inherits from an object D. One of my colleagues proposed that we don't use serial (integer + sequence) primary keys for these objects, but that we use the very same integer primary keys. That is : the instance A would use the id 12343, and the instance B the same id 12343 and the instance C the same id 12343 and the D instance the same id 12343. It's possible as two instances of an object never inherit from a same instance of another object. The id seems to me absolutely bad, but I wouldn't know how to phrase why. Any suggestion ? Thanks in advance, David. 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   to model a sweepsakes entry is a person, and you allow a person to enter a sweepstakes more than once, but to enter a contest the user must provide a unique email address, then you could not just use a foreign key as the primary key in sweepstakes, since the primary key would disallow multiple entries in sweepstakes entry, you would then use a serial data type in both person and sweepstakes along with the foriegn key in sweepstakes from person.   The answer depends on the need. Hope that helps.   Russ