Czy powinienem dodać kolumnę typu do dziedziczenia projektu w postgreSQL?

Na pewno możesz to zrobić, na przykład, aby wymusić, że tylko jedna podtabela może odwoływać się do danego wiersza:

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)
);

Teraz nie ma możliwości odwoływania się do wiersza w Super_Table przez wiersz w obu podtablicach. Wiersz w Super_Table musi zawierać „A” lub „B”, więc tylko jedna z podtabeli może spełniać odwołanie do klucza obcego.

Odpowiedz na swój komentarz:

Rozumiem, że obecna implementacja INHERITS w PostgreSQL dopuszcza szereg anomalii związanych z indeksami, unikalnymi ograniczeniami i ograniczeniami kluczy obcych. Korzystanie z tej funkcji jest trudne i podatne na błędy.

Zasadniczo, ponieważ indeksy istnieją tylko w jednej tabeli, jeśli masz unikatowe ograniczenie w tabeli nadrzędnej, to w jaki sposób może ona wymusić tę unikalność w odniesieniu do rodzica i wszystkich jego dzieci? Dzieci mogą wstawić do swoich tabel wartości, które już istnieją w rodzicu, lub rodzic może wstawić wartość, która już istnieje w jednym z dzieci.

Podobnie klucze obce nie mogą odwoływać się do tabeli nadrzędnej i/lub jej dzieci, ponieważ nie jest jednoznaczne, do którego wiersza się odwołuje, jeśli wiele wierszy może istnieć w nadrzędnym/podrzędnym z tym samym kluczem podstawowym lub unikalną wartością.

Są to znane i nierozwiązane ograniczenia INHERITS w PostgreSQL. Projekt, który pokazałem powyżej, rozwiązuje problem z kluczem podstawowym, ale nie z drugorzędnymi kluczami unikalnymi.

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