"Eredità della tabella" significa qualcosa di diverso da "eredità della classe" e servono a scopi diversi.
Postgres è incentrato sulle definizioni dei dati. A volte definizioni di dati davvero complesse. OOP (nel senso comune delle cose color Java) riguarda la subordinazione dei comportamenti alle definizioni dei dati in una singola struttura atomica. Lo scopo e il significato della parola "eredità" qui sono significativamente diversi.
In terra OOP potrei definire (essendo molto sciolto con la sintassi e la semantica qui):
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)
Le tabelle per questo potrebbero essere simili a:
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);
Ma dove sono i comportamenti? Non si adattano da nessuna parte. Questo non è lo scopo degli "oggetti" così come vengono discussi nel mondo dei database, perché i database riguardano i dati, non il codice procedurale. Potresti scrivere funzioni nel database per fare calcoli per te (spesso un'idea molto buona, ma non proprio qualcosa che si adatta a questo caso) ma le funzioni non sono la stessa cosa dei metodi - metodi intesi nella forma di OOP di cui stai parlando circa sono volutamente meno flessibili.
C'è ancora una cosa da sottolineare sull'ereditarietà come dispositivo schematico: a partire da Postgres 9.2 non c'è modo di fare riferimento a un vincolo di chiave esterna su tutte le partizioni / membri della famiglia di tabelle contemporaneamente. Puoi scrivere controlli per farlo o aggirarlo in un altro modo, ma non è una funzionalità incorporata (si tratta di problemi con un'indicizzazione complessa, davvero, e nessuno ha scritto i bit necessari per renderlo automatico). Invece di utilizzare l'ereditarietà delle tabelle per questo scopo, spesso una migliore corrispondenza nel database per l'ereditarietà degli oggetti consiste nel creare estensioni schematiche alle tabelle. Qualcosa come questo:
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);
Ora abbiamo un riferimento canonico per l'istanza dell'animale che possiamo usare in modo affidabile come riferimento di chiave esterna, e abbiamo una colonna "ilk" che fa riferimento a una tabella di definizioni xxx_ilk che punta alla "prossima" tabella di dati estesi ( o indica che non ce n'è se il tipo è il tipo generico stesso). Scrivere funzioni di tabella, viste, ecc. Su questo tipo di schema è così facile che la maggior parte dei framework ORM fa esattamente questo genere di cose in background quando si ricorre all'ereditarietà delle classi in stile OOP per creare famiglie di tipi di oggetti.