"L'héritage de Table" signifie quelque chose de différent que "l'héritage de classe" et qu'ils servent à des fins différentes.
Postgres est tout au sujet de la définition des données. Parfois très complexes et les définitions de données. La programmation orientée objet (dans la commune de Java-couleur sens des choses), c'est à propos de la subordination des comportements à des définitions de données dans une seule structure atomique. Le but et le sens du mot "héritage" est significativement différente ici.
En programmation orientée objet, la terre je pourrais définir (très lâche avec la syntaxe et de la sémantique ici):
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)
Les tables de ce qui pourrait ressembler à:
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);
Mais où sont les comportements? Ils ne correspondent pas n'importe où. Ce n'est pas le but des "objets", comme ils sont décrits dans la base de données du monde, parce que les bases de données sont des données, pas de code procédural. Vous pourriez écrire des fonctions dans la base de données pour effectuer des calculs pour vous (souvent une très bonne idée, mais pas vraiment quelque chose qui correspond à ce cas), mais les fonctions ne sont pas la même chose que de méthodes-méthodes comme compris dans la forme de la programmation orientée objet vous parlez, sont délibérément moins souple.
Il n'y a plus qu'une chose à souligner à propos de l'héritage comme un schéma de l'appareil: Comme de Postgresql 9.2 il n'y a pas moyen de faire référence à une contrainte de clé étrangère sur toutes les partitions/tableau des membres de la famille à la fois. Vous pouvez écrire des vérifications à faire ceci ou à obtenir autour de lui d'une autre manière, mais ce n'est pas une fonctionnalité intégrée (on en vient à des questions complexes d'indexation, vraiment, et personne n'a rédigé les bits nécessaires pour assurer automatique). Au lieu d'utiliser l'héritage de table pour cet effet, souvent une meilleure correspondance dans la base de données pour l'objet de l'héritage est de faire des extensions de schéma de tables. Quelque chose comme ceci:
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(2o) 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);
Maintenant, nous avons une représentation canonique de référence pour l'instance de l'animal que l'on peut utiliser fiable comme une référence de clé étrangère, et nous avons un "ilk" colonne qui fait référence à une table de xxx_ilk définitions qui pointe à la "prochaine" table de données étendu (ou indique qu'il n'y est aucune si l'image est de type générique lui-même). L'écriture de fonctions de table, vue, etc. face à ce type de schéma est tellement facile que la plupart des frameworks ORM faire exactement ce genre de chose en arrière-plan lorsque vous avez recours à de la programmation orientée objet-classe de style héritage de créer des familles de types d'objet.
