Единственное Наследование Таблицы (Проектные решения Наследования базы данных) за и против и, в этом случае это использовало?
Сегодня, я учился о приблизительно 2 подходах наследования проектирования баз данных:
По моему студенческому мнению Единственное Наследование Таблицы делает базу данных меньшей по сравнению с другими подходами, потому что это использует только 1 таблицу. Но я считал, что более благоприятный подход является Наследованием Таблицы Класса по словам Bill Karwin.
Каковы за и против Единственного Наследования Таблицы, и, в этом случае оно должно использоваться?
1 ответ
По мнению моего студента, наследование одной таблицы делает базу данных более компактной по сравнению с другими подходами, потому что она использует только одну таблицу.
Не обязательно. Если сущности вашей иерархии имеют мало общих атрибутов, это приведет к появлению множества нулевых столбцов и к потере много места.
Но я читал, что более популярным подходом является наследование таблиц классов (Class Table Inheritance) по Биллу Карвину.
ИМХО, единого ответа нет, различные стратегии (одна таблица на иерархию, одна таблица на конкретный класс, одна таблица на класс) имеют все сильные и слабые стороны, и выбор той или иной зависит от контекста.
Наследование одной таблицы - плюсы и минусы и в каких случаях оно используется?
Эта стратегия хороша, когда вам нужны "полиморфные" запросы (не нужны соединения или объединения), пока вы можете минимизировать количество нулевых столбцов (и убедить DBA, что денормализованная схема не будет проблемой в долгосрочной перспективе).
На самом деле, я предлагаю ознакомиться с Mapping Objects to Relational Databases: O/R Mapping In Detail Скотта Амблера (автора справочника по ORM) и особенно раздел 2.6 Comparing The Strategies- нет смысла его пересказывать.
Его резюме стратегии "одной таблицы":
Преимущества:
- Простой подход.
- Легко добавлять новые классы, вам просто нужно добавить новые колонки для дополнительных данных.
- Поддерживает полиморфизм простым изменением типа строки.
- Быстрый доступ к данным, поскольку данные находятся в одной таблице.
- Специальная отчетность очень проста, потому что все данные находятся в одной таблице.
Недостатки:
- Связь в иерархии классов увеличивается, потому что все классы непосредственно связаны с одной и той же таблицей. A изменение в одном классе может повлиять на таблицу, которая затем может повлиять на другие классы в иерархии.
- Потенциально неиспользуемое пространство в базе данных.
- Указание типа становится сложным, когда существует значительное перекрытие между типами. существует.
- Таблица может быстро расти для больших иерархий.
Когда использовать:
- Это хорошая стратегия для простых и/или неглубоких иерархий классов, где существует небольшое или полное перекрытие между типами в иерархии.
Но я от всей души рекомендую прочитать статью целиком.