„Dziedziczenie tabeli” oznacza coś innego niż „dziedziczenie klas” i służą one innym celom.
Postgres dotyczy definicji danych. Czasami naprawdę złożone definicje danych. OOP (w typowym znaczeniu dla języka Java) polega na podporządkowaniu zachowań definicjom danych w pojedynczej strukturze atomowej. Cel i znaczenie słowa „dziedziczenie” są tutaj znacząco inne.
W krainie OOP mogę zdefiniować (będąc tutaj bardzo luźnym ze składnią i semantyką):
import life
class Animal(life.Autonomous):
metabolism = biofunc(alive=True)
def die(self):
self.metabolism = False
class Mammal(Animal):
hair_color = color(foo=bar)
def gray(self, mate):
self.hair_color = age_effect('hair', self.age)
class Human(Mammal):
alcoholic = vice_boolean(baz=balls)
Tabele do tego mogą wyglądać następująco:
CREATE TABLE animal
(name varchar(20) PRIMARY KEY,
metabolism boolean NOT NULL);
CREATE TABLE mammal
(hair_color varchar(20) REFERENCES hair_color(code) NOT NULL,
PRIMARY KEY (name))
INHERITS (animal);
CREATE TABLE human
(alcoholic boolean NOT NULL,
FOREIGN KEY (hair_color) REFERENCES hair_color(code),
PRIMARY KEY (name))
INHERITS (mammal);
Ale gdzie są zachowania? Nigdzie nie pasują. Nie jest to celem „obiektów”, ponieważ są one omawiane w świecie baz danych, ponieważ bazy danych dotyczą danych, a nie kodu proceduralnego. Możesz zapisać funkcje w bazie danych, aby wykonać obliczenia za Ciebie (często bardzo dobry pomysł, ale nie jest to coś, co pasuje do tego przypadku), ale funkcje to nie to samo co metody - metody rozumiane w postaci OOP, o którym mówisz około są celowo mniej elastyczne.
Jest jeszcze jedna rzecz, na którą należy zwrócić uwagę, jeśli chodzi o dziedziczenie jako urządzenie schematyczne: od Postgres 9.2 nie ma możliwości odniesienia się do ograniczenia klucza obcego dla wszystkich członków rodziny partycji / tabel jednocześnie. Możesz napisać kontrole, aby to zrobić, lub obejść to w inny sposób, ale nie jest to wbudowana funkcja (sprowadza się do problemów ze złożonym indeksowaniem, a nikt nie napisał bitów niezbędnych do wykonania tego automatycznego). Zamiast używać dziedziczenia tabel do tego celu, często lepszym rozwiązaniem w bazie danych dla dziedziczenia obiektów jest tworzenie schematycznych rozszerzeń tabel. Coś takiego:
CREATE TABLE animal
(name varchar(20) PRIMARY KEY,
ilk varchar(20) REFERENCES animal_ilk NOT NULL,
metabolism boolean NOT NULL);
CREATE TABLE mammal
(animal varchar(20) REFERENCES animal PRIMARY KEY,
ilk varchar(20) REFERENCES mammal_ilk NOT NULL,
hair_color varchar(20) REFERENCES hair_color(code) NOT NULL);
CREATE TABLE human
(mammal varchar(20) REFERENCES mammal PRIMARY KEY,
alcoholic boolean NOT NULL);
Teraz mamy odwołanie kanoniczne do instancji zwierzęcia, którego możemy niezawodnie użyć jako odniesienia do klucza obcego, i mamy kolumnę „podobną”, która odwołuje się do tabeli definicji xxx_ilk, która wskazuje na „następną” tabelę danych rozszerzonych ( lub wskazuje, że nie ma żadnego, jeśli podobny jest sam typem ogólnym). Pisanie funkcji tabel, widoków itp. W tego rodzaju schemacie jest tak łatwe, że większość frameworków ORM robi dokładnie tego rodzaju rzeczy w tle, kiedy uciekasz się do dziedziczenia klas w stylu OOP, aby utworzyć rodziny typów obiektów.