Я буду использовать LLBLGen для генерации модели, однако я не хочу решать свои проблемы проектирования, просто используя все встроенные инструменты наследования. Я хочу, чтобы модель имела смысл независимо от инструмента OR / M.
Итак, у меня есть несколько видов сущностей, которые могут иметь адреса, и каждая сущность может иметь несколько адресов (основной, почтовый и т. Д.).
Вариант 1, использует Супертип / Подтип (Если вы знаете точное название схемы такого рода, это было бы полезно)
Таблица:
EntityType [EntityTypeID, EntityTypeName] (скажем, Company = 1,
Сотрудник = 2, AnotherEntity = 3)
Entity: [EntityID, EntityTypeID, OriginID]: EntityTypeID => EntityType
Компания: [CompanyID, CompanyName, ...]
Сотрудник: [EmployeeID, FirstName, ...]
AddressType: [AddressTypeID, AddressTypeName] (скажем, Primary = 1, Mailing = 2 и т. Д.)
Адрес: [AddressID, AddressTypeID, EntityID, StreetAddress1, ...]: AddressTypeID => AddressType, EntityID => Entity
Способ, которым это будет работать, заключается в том, что перед созданием любой Компании или Сотрудника необходимо создать запись Entity с соответствующим заполнением EntityType. Затем создается Компания или Сотрудник, и для Entity.OriginID устанавливается идентификатор Компании или Сотрудника. Теперь записи Address будут принадлежать записям Entity, которые будут «привязаны» к конкретным представлениям EntiteTID EntityType и OriginID.
Я немного беспокоюсь обо всех соединениях, которые для этого потребуются. И даже более того, я немного обеспокоен тем, что это будет неуклюжим в моем инструменте ORM (LLBLGen).
Вариант 2, это своего рода вариант с вариантом 1. Я думаю, что, вероятно, хуже, но с учетом того же:
Таблица:
EntityType: [EntityTypeID, EntityTypeName] (скажем, компания = 1, сотрудник = 2, AnotherEntity = 3)
Entity: [EntityID, EntityTypeID]: EntityTypeID => EntityType
Компания: [CompanyID, EntityID, CompanyName, ...]: EntityID => Entity
Сотрудник: [EmployeeID, EntityID, FirstName, ...]: EntityID => Entity
AddressType: [AddressTypeID, AddressTypeName] (скажем, Primary = 1, Mailing = 2 и т. Д.)
Адрес: [AddressID, AddressTypeID, EntityID, StreetAddress1, ...] AddressTypeID
=> AddressType, EntityID => Entity
Это будет работать аналогично варианту 1, в котором для компании или сотрудника сначала будет создана запись сущности с соответствующей настройкой типа сущности. Затем будет создана запись о компании или сотруднике, а ранее созданная запись EntityID объекта будет указана в самой записи компании или сотрудника. Адрес будет привязан к самой сущности. Однако это кажется странным, поскольку это будет относиться к записям адресов, таким как записи компаний и сотрудников, то есть они содержат EntityID, но эта ссылка означает нечто иное, чем ссылки EntityID в таблицах компаний и сотрудников.
Кажется, это немного хуже. У него почти те же проблемы, что и у первой, но я думаю, что она делает схему менее интуитивно понятной.
В обоих случаях вам нужно будет использовать некоторые уникальные ограничения, например, в таблице Company (EntityID должен быть уникальным в таблице Company). Однако вам потребуется выполнить другую программную проверку, чтобы предотвратить запись компании и сотрудника на одну и ту же запись объекта. Я не знаю, может ли такой инструмент, как LLBLGen, творить «магию» с Вариантом 1, разумно работая со значениями EntityTypeID.
Итак, вариант 3 прост:
Таблица:
Компания: [CompanyID, CompanyName, ...]
Employee [EmployeeID, FirstName, ...]
AddressType: [AddressTypeID, AddressTypeName] (скажем, Primary = 1, Mailing = 2 и т. Д.)
CompanyAddress: [CompanyAddressID, AddressTypeID, CompanyID, StreetAddress1, ...]:
AddressTypeID => AddressType,CompanyID => Компания
EmployeeAddress: [EmployeeAddressID, AddressTypeID, EmployeeID, StreetAddress1, ...]:
AddressTypeID => AddressType,
EmployeeID => Сотрудник
Это значительно облегчает работу с соединениями. Однако я не думаю, что это действительно выполнимо. У меня много сущностей. У меня не только много сущностей, но и много сущностей, которые могут иметь адрес. Кроме того, этот адресный материал - только один пример, у меня есть много других вещей, которые похожи на адреса. Я не думаю, что создание таблицы для каждого из них будет очень масштабным с точки зрения развития. Кроме того, я уверен, что смогу заставить свой ORM позволить мне использовать код для обработки всех разных адресов как одного и того же базового типа «Адрес», но, опять же, я не хочу полагаться на приемы, которые может выполнять ORM.
Итак, эта вещь Супертипа / Подтипа - хорошая идея (я подозреваю, что нет)? Если это так, есть ли лучший способ сделать это? Если нет, то какие есть лучшие альтернативы.