Наследование в одной таблице (варианты проектирования базы данных) плюсы и минусы и в каком случае оно используется?

Question

Сегодня я изучил около 2 подходов наследования проектирования баз данных:

1. Наследование в одной таблице
2. Наследование таблицы классов

По моему мнению студента, Наследование одной таблицы делает базу данных меньше по сравнению с другими подходами, потому что она использует только 1 таблицу. Но я читал, что более благоприятный подход - Наследование таблиц классов по Биллу Карвину.

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

Answer 1

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

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

Но я читал, что более любимый подход - это наследование таблиц классов согласно Биллу Карвину.

ИМХО, единого ответа не существует, разные стратегии (одна таблица на иерархию, одна таблица на конкретный класс, одна таблица на класс) имеют все сильные и слабые стороны, и выбор того или другого зависит от контекста.

Единичное наследование таблицы за и против и в каком случае оно используется?

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

На самом деле, я предлагаю проверить Отображение объектов в реляционных базах данных: подробное отображение O / R Скотта Амблера (автора справочного документа по ORM) и особенно раздел 2.6 Сравнение Стратегии - перефразировать его нет смысла.

Его краткое изложение стратегии единой таблицы:

Преимущества:

• Простой подход.
• Легко добавлять новые классы, вам просто нужно добавить новые столбцы для дополнительные данные.
• Поддерживает полиморфизм путем простого изменения типа строки.
• Быстрый доступ к данным, поскольку данные находятся в одной таблице.
• Специальная отчетность очень проста, потому что все данные находятся в один стол

Недостатки:

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

Когда использовать:

• Это хорошая стратегия для простых и / или неглубокие иерархии классов, где между или почти нет совпадений типы в иерархии.

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

Answer 2

Наследование одной таблицы - хороший подход, когда подклассы не имеют много атрибутов или ассоциаций с другими классами. В противном случае таблица будет заполнена атрибутами, которые имеют смысл только для некоторых кортежей таблицы, и вам нужно будет добавить все виды ограничений, чтобы убедиться, что они содержат значения только для кортежей соответствующего «типа».

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