"Herencia de tabla" significa algo diferente a "herencia de clase" y sirven para diferentes propósitos.
Postgres se trata de definiciones de datos. A veces, definiciones de datos realmente complejas. OOP (en el sentido común de las cosas del color de Java) se trata de subordinar comportamientos a definiciones de datos en una sola estructura atómica. El propósito y el significado de la palabra "herencia" es significativamente diferente aquí.
En OOP land podría definir (siendo muy flexible con la sintaxis y la semántica aquí):
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)
Las tablas para esto podrían verse así:
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);
Pero, ¿dónde están los comportamientos? No caben en ninguna parte. Este no es el propósito de los "objetos" como se discuten en el mundo de las bases de datos, porque las bases de datos están relacionadas con datos, no con códigos de procedimiento. Puede escribir funciones en la base de datos para hacer cálculos por usted (a menudo es una muy buena idea, pero no es realmente algo que se ajuste a este caso), pero las funciones no son lo mismo que los métodos: métodos tal como se entienden en la forma de POO que está hablando sobre son deliberadamente menos flexibles.
Hay una cosa más que señalar sobre la herencia como dispositivo esquemático: a partir de Postgres 9.2, no hay forma de hacer referencia a una restricción de clave externa en todas las particiones / miembros de la familia de tablas a la vez. Puede escribir cheques para hacer esto o evitarlo de otra manera, pero no es una característica incorporada (se reduce a problemas con la indexación compleja, en realidad, y nadie ha escrito los bits necesarios para que eso sea automático). En lugar de usar la herencia de tablas para este propósito, a menudo una mejor coincidencia en la base de datos para la herencia de objetos es hacer extensiones esquemáticas a las tablas. Algo como esto:
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);
Ahora tenemos una referencia canónica para la instancia del animal que podemos usar de manera confiable como referencia de clave externa, y tenemos una columna "calaña" que hace referencia a una tabla de definiciones xxx_ilk que apunta a la tabla "siguiente" de datos extendidos ( o indica que no hay ninguno si el tipo es el tipo genérico en sí). Escribir funciones de tabla, vistas, etc. contra este tipo de esquema es tan fácil que la mayoría de los marcos de ORM hacen exactamente este tipo de cosas en segundo plano cuando se recurre a la herencia de clases de estilo OOP para crear familias de tipos de objetos.
