Moet ik een typekolom toevoegen om overerving in postgreSQL te ontwerpen?

Natuurlijk kun je dit bijvoorbeeld doen om af te dwingen dat slechts één subtabel naar een bepaalde rij kan verwijzen:

CREATE TABLE Super_Table (
  super_id SERIAL PRIMARY KEY,
  sub_type CHAR(1) NOT NULL,
  UNIQUE KEY (super_id, sub_type) 
);

CREATE TABLE Sub_Table_A (
  super_id PRIMARY KEY,
  sub_type CHAR(1) NOT NULL,
  CHECK (sub_type = 'A'),
  FOREIGN KEY (super_id, sub_type) REFERENCES Super_Table (super_id, sub_type)
);

CREATE TABLE Sub_Table_B (
  super_id PRIMARY KEY,
  sub_type CHAR(1) NOT NULL,
  CHECK (sub_type = 'B'),
  FOREIGN KEY (super_id, sub_type) REFERENCES Super_Table (super_id, sub_type)
);

Nu kan er op geen enkele manier naar een rij in Super_Table worden verwezen door een rij in beide subtabellen. De rij in Super_Table moet ofwel 'A' of 'B' hebben en dus kan slechts één van de subtabellen voldoen aan de refererende sleutelreferentie.

Over uw opmerking:

Ik heb begrepen dat de huidige PostgreSQL-implementatie van INHERITS een aantal anomalieën toestaat die verband houden met indexen, unieke beperkingen en externe sleutelbeperkingen. Het gebruik van deze functie is lastig en foutgevoelig.

Kortom, omdat indexen slechts over één enkele tabel bestaan, als u een unieke beperking op uw bovenliggende tabel heeft, hoe kan deze dan die uniciteit afdwingen over de bovenliggende tabel en al zijn kinderen? De kinderen kunnen waarden invoegen in hun tabellen die al in de bovenliggende tabel bestaan, of de bovenliggende kan een waarde invoegen die al bestaat in een van de kinderen.

Evenzo kunnen externe sleutels niet verwijzen naar de bovenliggende tabel en/of de onderliggende tabel, omdat het dubbelzinnig is naar welke rij wordt verwezen als er meerdere rijen kunnen bestaan ​​in bovenliggende/onderliggende items met dezelfde primaire sleutel of unieke waarde.

Dit zijn bekende en onopgeloste beperkingen van INHERITS in PostgreSQL. Het ontwerp dat ik hierboven liet zien, lost het probleem op voor de primaire sleutel, maar niet voor de secundaire unieke sleutels.

http://archives.postgresql.org/pgsql-hackers/2010 -05/msg00285.php