Каковы плюсы и минусы использования наследования в базе данных

Question

Я проектирую базу данных в Postgresql. Я хотел бы знать, каковы плюсы и минусы использования наследования.

Я также хотел бы знать следующее:

1. Влияние на производительность базы данных (т.е. вставка, обновление, удаление, индексирование и т. Д.)?

2. Означает ли родитель / ребенок дублированный ввод [ внутренне ]?

3. Обычно ли он используется в базах данных Postgresql?

4. Как это лучше, чем использовать FK, кроме простоты использования?

5. Должно ли оно использоваться для хранения общих и повторяющихся атрибутов, которые используются по всей базе данных (например, идентификатор, имя, метки времени и т. Д.)

Answer 1

Влияние на производительность базы данных (т.е. вставить, обновить, удалить, индексировать и т. д.)?

Не сильно пострадали, потому что другие методы для достижения того же результата также влияют на производительность.

Значит ли родитель / ребенок дубликат ввод [внутренне]?

Вы имеете в виду дублированные данные? Нет.

Это обычно используется в Postgresql базы данных?

Не то, что я знаю, но, честно говоря, это не так много говорит.

Как это лучше, чем использовать FK другой чем простота использования? Его полезность должна определяться в каждом конкретном случае. Лично я использовал его только для разделения таблиц. Это простота использования может быть обманчивым, когда это усложняет другие вещи. Например, ограничения не применяются к родительской и дочерней таблице в целом, а относятся только к таблице, в которой они определены, поэтому уникальное ограничение может не выполнять то, что вы хотите.

Должен ли он использоваться с целью хранить общий и повторяющийся атрибуты, которые используются во всем база данных (например, идентификатор, имя, время штампы и т.д.)

Не думаю, что это хорошая идея. Отношения наследования должны быть осмысленными, если они используются только для того, чтобы сэкономить вам немного труда, а теперь только запутают вас и других.

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

Answer 2

После краткого ознакомления с частью учебника, на которую указывалось:

"Влияние на производительность базы данных (т.е. вставка, обновление, удаление, индексирование и т. Д.)?"

Производительностьсоображения были, вероятно, самой причиной, по которой была изобретена конструкция.

«Означает ли родитель / ребенок дублированный ввод [внутренне]?»

Предположительно, нет.Похоже, что внутренняя реализация будет основана на таких вещах, как ROWID ().Я бы пошел по этому пути, если бы мне пришлось реализовать такую ​​функцию, и я сомневаюсь, что какой-либо инженер СУБД будет думать иначе.

«Чем это лучше, чем использовать FK, кроме простоты использования?»

Я бы держался подальше от этого и использовал бы «правильный» дизайн с ФК.«Простота использования» может быть качеством этой технологии наследования, которая существует, только если вы посмотрите на нее достаточно поверхностно.Я ожидаю, что под поверхностью будет много неприятных сюрпризов, таких как те, что описаны в конце урока.Один из описаний ключей, который, насколько я понимаю, по-прежнему допускает дублирование строк, для меня просто убийца.Я имею в виду, ключи, которые допускают дубликаты, насколько безумными вы можете их получить?

Еще одна причина, по которой я бы остался в стороне, заключается в том, что я не знаю наверняка, является ли это стандартным SQL.

«Должно ли оно использоваться с разумом ...»

Если ключи больше не являются декларациями уникальности, единственное, что я могу удивиться, это то, куда ушла вся причина.

Answer 3

Я успешно использовал наследование таблиц, но только для общих атрибутов, необходимых для многих таблиц, а не для наследования «класса».

Примерно так:

CREATE TABLE base (
  uuid UUID NOT NULL DEFAULT uuid_generate_v4(),
  name VARCHAR(320) NOT NULL,
  updated_by UUID NOT NULL DEFAULT uuid_nil(),
  updated TIMESTAMP NOT NULL DEFAULT current_timestamp
);

CREATE TABLE child (
  childata TEXT NOT NULL DEFAULT '',
)
INHERITS (base);

Где я использую base для хранения данных, необходимых для ряда таблиц.Обратите внимание, что я на самом деле не помещаю что-либо в базовую таблицу (принудительно отменяя все привилегии).Каждая дочерняя таблица хранит свой собственный uuid, имя и т. Д. Этот метод действительно просто сохраняет копирование / вставку.Это не может быть огромной экономией, поскольку каждая дочерняя таблица по-прежнему должна иметь PK, FK и индексы, определенные отдельно.

Недостатком этого является то, что вы не можете выполнять запросы по name для всех таблиц без объединений,Если вы пытаетесь выполнить наследование классов, это может быть требованием.

Что-то вроде человека с подклассом сотрудника может быть лучше смоделировано как таблица человека с общими данными и таблица сотрудника с данными «подкласса», которая имеет1-к-1 ссылка на человека.Это должно работать очень хорошо, так как вы присоединитесь к PK.При поиске будет выполнен запрос к таблице лиц, а затем вы сможете выполнить внешние объединения для данных о сотрудниках (используя NULL, чтобы подразумевать, что человек против сотрудника).