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

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

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

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

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

Источник

2 ответа

Решение

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

Источник

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

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

Источник
Другие вопросы по тегам