Способы наследования базы данных?
Каковы советы / методы, когда вам нужно сохранить классы с наследованием в реляционной базе данных, которая не поддерживает наследование?
Скажем, у меня есть классический пример:
Person -> Employee -> Manager
-> Team lead
-> Developer
-> Customer -> PrivilegedCustomer
-> EnterpriseCustomer
Какие есть доступные методы для разработки базы данных? Плюсы и минусы каждого?
p.s. Я искал и нашел несколько вопросов, касающихся наследования базы данных, но большинство из них касалось перехода на механизм базы данных, который поддерживает его изначально. Но допустим, я застрял на SQL Server 2005 ... какие у меня варианты?
Ответы 3
Три общие стратегии:
Создайте таблицу для каждого класса в иерархии, содержащую свойства, определенные для каждого класса, и внешний ключ для возврата к таблице суперкласса верхнего уровня. Таким образом, у вас может быть таблица
vehicleс другими таблицами, такими какcarиairplane, в которых есть столбецvehicle_id. Недостатком здесь является то, что вам может потребоваться выполнить много объединений только для того, чтобы получить один тип класса.Создайте таблицу для каждого класса в иерархии, содержащую все свойства. Это может быть сложно, поскольку нелегко поддерживать общий идентификатор для всех таблиц, если вы не используете что-то вроде последовательности. Запрос для типа суперкласса потребует объединений для всех рассматриваемых таблиц.
Создайте одну таблицу для всей иерархии классов. Это исключает объединения и объединения, но требует, чтобы все столбцы для всех свойств класса находились в одной таблице. Вероятно, вам придется оставить большинство столбцов обнуляемыми, поскольку некоторые столбцы не будут применяться к записям другого типа. Например, таблица
vehicleможет содержать столбец с именемwingspan, который соответствует типуAirplane. Если вы сделаете этот столбец НЕ ПУСТОЙ, тогда для любого экземпляраCar, вставленного в таблицу, потребуется значение дляwingspan, даже если значениеNULLможет иметь больше смысла. Если вы оставите столбец обнуляемым, вы сможете обойти это с помощью проверочных ограничений, но это может стать некрасивым. (Наследование одной таблицы)
Меня беспокоит сложность запроса. Для правильной работы может потребоваться несколько уловок со стороны DAL.
Для сложности запроса №3 звучит лучше всего. Кроме того, в некоторых СУБД (например, Postgres) вы можете обеспечить ненулевое значение для каждого конкретного подтипа с помощью ограничения проверки, даже если все столбцы будут иметь значение NULL.
Я не знаю, возможен ли это, но вы не используете 1. и используете представления для доступа к данным, таким образом, вы получаете соединения только в одном месте?
Глава 8. Сопоставление наследования в следующей ссылке также обсуждает это. http://nhibernate.info/doc/nh/en/index.html#inheritance
Это документ NHibernate.
Будьте осторожны с наследованием базы данных в определенных ситуациях - мы реализовали это в нашем приложении для нашей стратегии аудита, и в итоге мы получили узкое место / кошмар производительности.
Проблема заключалась в том, что базовая таблица, которую мы использовали, была только вставляемой и быстро менялась, поэтому в итоге мы получили тупиковые ситуации все на месте. В настоящее время мы планируем разбить их на отдельные таблицы, потому что головная боль от наличия одних и тех же столбцов в 15 разных таблицах по сравнению с кошмаром производительности того стоит. Это также усугублялось тем фактом, что структура сущностей не обязательно эффективно обрабатывает наследование (это известная проблема Microsoft).
Во всяком случае, просто подумал, что поделюсь некоторыми знаниями, так как мы прошли через отжим по этой проблеме.
Итак, вы делали №1 и переходите (переехали) в №2? (решений cliff.meyers)
Связанный вопрос: stackoverflow.com/questions/190296/…