Использование наследования в PostgreSQL

Question

Для кого-то, кто имеет опыт использования наследования в PostgreSQL: стоит ли его использовать или лучше нет? В какой ситуации вы бы это использовали?

Если честно, я не до конца понимаю разницу между реляционными и ОО-моделями ...

Answer 1

Вероятно, нет, есть предостережения в отношении наследования таблиц PostgreSQL, такие как отсутствие глобально уникальных ограничений, поэтому вы теряете многие гарантии согласованности. Также написание хорошо выполняющих запросов может быть довольно сложной задачей. Как отмечает Скотт, наследование PostgreSQL действительно полезно только для разбиения таблиц, где это компромисс производительности с самого начала.

Существует 2 распространенных способа использования стандартных идиом SQL для наследования классов:

• Каждый объект имеет отдельную строку в таблице суперкласса, а объекты подкласса также имеют строку в таблице, относящейся к подклассу, которая ссылается на поля суперкласса с помощью ссылки на внешний ключ.
• Просто объедините все поля суперкласса и подкласса в одну большую таблицу и оставьте их равными NULL, если их значение не применимо. Это особенно хорошо работает в PostgreSQL, поскольку значения NULL занимают только 1 бит на строку, а добавление / удаление полей в существующих таблицах происходит очень быстро (независимо от объема данных). Вы могли бы написать триггер для проверки наличия обязательных полей для определенного типа класса.

Answer 2

Это хорошо, но перед использованием убедитесь, что вы понимаете предостережения, изложенные в руководстве. В настоящее время способ обработки ограничений немного грубоват, но он находится в списке задач. Это особенно полезно при разбиении. Более подробный пример ОО был бы унаследован от таблицы сотрудников для создания таблицы сотрудников.

Конечно, недостатком является то, что он не переносим на другие rdbms, поэтому, если вам пришлось переназначить базу данных на другой rdbms, вам придется переписать кучу вещей.