Сегодня я изучил примерно 2 подхода к наследованию дизайна базы данных:
По моему мнению студента, наследование одной таблицы делает базу данных меньше по сравнению с другими подходами, поскольку использует только 1 таблицу. Но я читал, что более благоприятным подходом является Наследование таблицы классов согласно Биллу Карвину.
Каковы плюсы и минусы наследования одной таблицы и в каком случае его следует использовать?
По моему мнению, наследование одной таблицы делает базу данных меньше по сравнению с другими подходами, потому что она использует только 1 таблицу.
Не обязательно. Если у сущностей вашей иерархии мало общих атрибутов, это приведет к большому количеству столбцов с нулевым значением и займет много места.
Но я читал, что более любимый подход — наследование таблицы классов согласно Биллу Карвину.
ИМХО, единого ответа нет, разные стратегии (одна таблица на иерархию, одна таблица на конкретный класс, одна таблица на класс) имеют все сильные и слабые стороны, и выбор той или иной зависит от контекста.
Плюсы и минусы наследования одной таблицы и в каком случае оно используется?
Эта стратегия удобна, когда вам нужны «полиморфные» запросы (не нужны объединения или объединения), если вы можете свести к минимуму количество столбцов, допускающих значение NULL (и убедить администратора базы данных, что денормализованная схема не будет проблемой в долгосрочной перспективе). .
На самом деле, я предлагаю проверить Сопоставление объектов с реляционными базами данных: подробное сопоставление O/R Скотт Амблер (автор справочного документа об ORM) и особенно раздел 2.6 Сравнение Стратегии — нет смысла его перефразировать.
Его краткое изложение стратегии единого стола:
Преимущества:
- Простой подход.
- Легко добавлять новые классы, вам просто нужно добавить новые столбцы для дополнительных данных.
- Поддерживает полиморфизм, просто изменяя тип строки.
- Доступ к данным быстрый, потому что данные находятся в одной таблице.
- Специальные отчеты очень просты, потому что все данные находятся в одной таблице.
Недостатки:
- Связь внутри иерархии классов увеличивается, поскольку все классы напрямую связаны с одной и той же таблицей. Изменение в одном классе может повлиять на таблицу, которая затем может повлиять на другие классы в иерархии.
- Пространство в базе данных может быть потрачено впустую.
- Указание типа становится сложным, когда существует значительное совпадение между типами.
- Таблица может быстро расти для больших иерархий.
Когда использовать:
- Это хорошая стратегия для простых и/или неглубоких иерархий классов, когда между типами в иерархии мало или совсем нет совпадений.
Но я настоятельно рекомендую прочитать всю статью.
Наследование одной таблицы — хороший подход, когда у подклассов не так много атрибутов или ассоциаций с другими классами. В противном случае таблица будет заполнена атрибутами, которые имеют смысл только для некоторых кортежей таблицы, и вам нужно будет добавить всевозможные ограничения, чтобы убедиться, что они содержат значения только для кортежей соответствующего «типа».
Кроме того, всем запросам, которые должны иметь дело только с экземплярами одного из подклассов, потребуется дополнительное предложение для их выбора на основе значения типа.
