Thanks Jake.
I can see many places where both options would be useful. Having
duplicate PKs in parent, and stricktly unique parent PK. Depending on
the reason for the inhertiance. (Eg, useing a parent as a template for
children, when duplicate PK's would be essential, or using parent as a
grouping for many similar relations with a common index structure, where
duplicate PK in parent would be a disauster...)
As long a these methods are controlable and understood, then they can be
used.
One thing I would like is for the UNIQUE() to be respected with
inheritence. Therefore:
CREATE TABLE parent (
a INTEGER PRIMARY KEY,
UNIQUE (a)
)
Therefore giving some control... But there may be better methods :)
Ben
Jake Stride wrote:
> On Wed, 2003-07-09 at 17:56, Ben Clewett wrote:
>
>>PostgreSQL,
>>
>>I've been following with interest the discussions on Inheritance, as we
>>are planning to use this.
>>
>>There may be alternate methods. I understand that a view on a master
>>table gives the same abilities. Although I have to wonder if after
>>multiple inheritance in both breadth and depth, whether the view method
>>would suffer very large master table and excessive maintenance issues.
>>But mainly the simplicity, and analogy to the OO techniques we are using
>>in code design, make this attractive. Looking specifically at
>>transactional relations, which have many foreign keys and specific data
>>for each instance of use. Inheriting the parent relation for a new type
>>of transaction as and when required, is appealing.
>>
>>I simply want to know whether it's a bug that the ancestor relations may
>>have duplicate entries on its PK, or just an unfortunate side effect of
>>inheritance?
>>
>>Thanks, Ben.
>>
>
>
> We use inheritence alonside OO techniques and it is very useful. The
> duplicate keys is (I beleive) because of the way the relationship is
> inherited using directed graphs.
>
> The way that we have overcome the problem is so:
>
> create table a (id bigserial, ...., primary key(id));
>
> create table b (id bigserial, ..., primary key(id)) inherits (a);
>
> This means that you will always have a unique key in the inherited table
> as it 'replaces' the original id.
>
> Does this answer the question or am I off the mark?
>
> Jake
>
