"Tabla de herencia" significa algo diferente de "herencia de clase" y sirven para diferentes propósitos.
Postgres tiene que ver con las definiciones de datos. A veces definiciones de datos realmente complejas. OOP (en el sentido común de las cosas de Java) se trata de subordinar los comportamientos a las definiciones de datos en una sola estructura atómica. El propósito y el significado de la palabra "herencia" es significativamente diferente aquí.
En POO tierra podría definir (siendo muy suelto con 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 de este aspecto:
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 ningún lado Este no es el propósito de los "objetos" como se discuten en el mundo de la base de datos, porque las bases de datos se preocupan por los datos, no por el código de procedimiento. Puede escribir funciones en la base de datos para hacer cálculos (a menudo una muy buena idea, pero no es algo que se adapte a este caso) pero las funciones no son lo mismo que los métodos: métodos como los entiende en forma de OOP de los que está hablando aproximadamente son deliberadamente menos flexibles.
Hay una cosa más que destacar 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 para solucionarlo de otra manera, pero no es una función incorporada (en realidad se trata de problemas con la indexación compleja y nadie ha escrito los bits necesarios para que sea automática).En lugar de utilizar 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 utilizar de forma fiable como una referencia de clave externa, y tenemos una columna de "calaña" que hace referencia a una tabla de definiciones xxx_ilk cuales apunta a la "próxima" tabla de datos ampliados (o indica que no hay ninguno si el tipo es el tipo genérico en sí). Escribir funciones de tablas, vistas, etc. en contra de este tipo de esquema es tan fácil que la mayoría de los marcos ORM hacen exactamente este tipo de cosas en segundo plano cuando recurre a la herencia de clase de estilo OOP para crear familias de tipos de objetos.
Otro ejemplo de partición –
En su artículo 1, ¿cómo entiende Postgres cuál de las tablas es necesaria para buscar? Usted selecciona de la tabla padre, y el rango de fechas es solo un ejemplo conveniente de división. La tabla padre no puede conocer esta lógica. ¿O estoy equivocado? –
Realizar una consulta en la tabla padre es, de hecho, lo mismo que realizar una consulta en UNION ALL en todas las tablas de descendientes en filas comunes. El planificador de consultas conoce las restricciones de verificación que definen cada partición y, siempre que no se superpongan, las utiliza para determinar que puede omitir las tablas de comprobación para las cuales CHECK indica que no se devolverán las filas. [Los documentos de Postgres en este] (http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html) – zxq9