«Наследование таблиц» означает нечто иное, чем «наследование классов», и они служат другим целям.
Postgres - это все об определениях данных. Иногда действительно сложные определения данных. ООП (в обычном понимании вещей цвета Java) - это подчинение поведения определениям данных в единой атомарной структуре. Назначение и значение слова «наследство» здесь существенно различаются.
В области ООП я мог бы определить (здесь очень нечетко с синтаксисом и семантикой):
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)
Таблицы для этого могут выглядеть так:
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);
Но где поведение? Они никуда не подходят. Это не цель «объектов», как они обсуждаются в мире баз данных, потому что базы данных связаны с данными, а не с процедурным кодом. Вы можете писать функции в базе данных для выполнения расчетов за вас (часто очень хорошая идея, но не совсем то, что подходит для этого случая), но функции - это не то же самое, что методы - методы, как они понимаются в форме ООП, о которой вы говорите about намеренно менее гибкие.
О наследовании как схематическом устройстве следует указать еще на одно: в Postgres 9.2 нет возможности ссылаться на ограничение внешнего ключа сразу для всех разделов / членов семейства таблиц. Вы можете написать чеки, чтобы сделать это или обойти это другим способом, но это не встроенная функция (на самом деле это сводится к проблемам со сложной индексацией, и никто не написал биты, необходимые для того, чтобы сделать это автоматическим). Вместо того, чтобы использовать для этой цели наследование таблиц, часто в базе данных для наследования объектов лучшим вариантом является создание схемных расширений таблиц. Что-то вроде этого:
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);
Теперь у нас есть каноническая ссылка на экземпляр животного, которую мы можем надежно использовать в качестве ссылки на внешний ключ, и у нас есть столбец «ilk», который ссылается на таблицу определений xxx_ilk, которая указывает на «следующую» таблицу расширенных данных ( или указывает, что его нет, если подобный тип сам является универсальным). Написание табличных функций, представлений и т. Д. На основе такой схемы настолько просто, что большинство фреймворков ORM делают именно такие вещи в фоновом режиме, когда вы прибегаете к наследованию классов в стиле ООП для создания семейств типов объектов.