使用共同點建模實體：超類型/子類型？

Question

我將使用LLBLGen來生成模型，但是我不想通過使用它所具有的任何內置繼承工具來解決我的設計問題。無論OR/M工具如何，我都希望模型有意義。

所以，我有幾種不同的實體可以有地址，每個實體可以有多個地址（主要的，郵件等）。

選項1，使用超類型/子類型（如果你知道這種方案的確切名稱，這將是有益的）

表： 的EntityType [EntityTypeID，EntityTypeName] （說，公司= 1， 僱員= 2，AnotherEntity = 3）

實體：[ENTITYID，EntityTypeID，OriginID]：EntityTypeID =>的EntityType

公司：[CompanyID，公司名稱，...]

僱員：僱員，姓，...]

地址類型：[AddressTypeID，AddressTypeName]（說，小學= 1，郵件= 2，等等）

地址：[AddressID，AddressTypeID，ENTITYID， StreetAddress1，...]：AddressTypeID =>地址類型，ENTITYID =>實體

這樣的工作的方式是創建的任何公司或員工之前，實體唱片則必須創建具有適當的EntityType填寫。然後創建公司或員工，並將Entity.OriginID設置爲公司或員工的ID。現在，地址記錄將屬於將「綁定」到具體實體的實體記錄，以查看EntityTypeID和OriginID。

我有點擔心這將需要所有的連接。更有甚者，我有點擔心這在我的ORM工具（LLBLGen）中會很笨拙。

選項2，這有點採取選項1.我覺得可能是雪上加霜，但包括它只是相同的：

表：

的EntityType：[EntityTypeID，EntityTypeName]（說，公司= 1，僱員= 2，AnotherEntity = 3）

實體：[ENTITYID，EntityTypeID]：EntityTypeID =>的EntityType

公司：[CompanyID，ENTITYID，公司名稱，...]：ENTITYID =>實體

僱員：僱員，ENTITYID，姓，...]：ENTITYID =>實體

地址類型：[AddressTypeID，AddressTypeName]（說，小學= 1，郵件= 2，等等）

地址：AddressID，AddressTypeID，ENTITYID，StreetAddress1，...] AddressTypeID =>地址類型，ENTITYID =>實體

這會工作類似於選項1，在一個公司或員工，一個實體記錄將首先創建，適當地設置EntityType。然後，將創建公司或員工記錄，並且之前創建的實體記錄的實體ID將在公司或員工記錄本身上設置。地址將被綁定到實體本身。但是，這看起來很奇怪，因爲這會處理Address記錄，例如Company和Employee記錄，即它們持有EntityID，但該引用意味着EntityID在Company和Employee表中引用的內容不同。

這似乎有點惡化。它與第一個問題幾乎有相同的問題，但它也使得模式不那麼直觀，我想。

在這兩種情況下，您都需要使用某些唯一約束，例如在公司表中（EntityID在公司表中應該是唯一的）。但是，您需要執行其他程序檢查以防止公司和員工記錄指向相同的實體記錄。我不知道像LLBLGen這樣的工具是否可以通過智能地處理EntityTypeID值來對Option 1做任何「魔術」。

所以，選項3非常簡單：

表：

公司：[CompanyID，公司名稱，...]

僱員[僱員，名字，...]

AddressType：[AddressTypeID，AddressTypeName]（Say，Primary = 1，Mailing = 2等）

CompanyAddress：[Compan yAddressID，AddressTypeID，CompanyID，StreetAddress1，...]： AddressTypeID =>地址類型， CompanyID =>公司

EmployeeAddress：[EmployeeAddressID，AddressTypeID，僱員，StreetAddress1，...]： AddressTypeID =>地址類型， EmployeeID =>員工

這使得連接更容易處理。但是，我不認爲這是可行的。我有很多實體。我不僅擁有很多實體，而且擁有很多可以擁有地址的實體。此外，這個「地址」的東西只是一個例子，我有許多其他類似的地址的東西。我不認爲爲每個人創造一張桌子都會在發展方面產生很大的影響。另外，我確定我可以讓我的ORM讓我使用代碼將所有不同的地址作爲同一個基本的「地址」類型來處理，但是我再也不想依賴ORM可以做的技巧。

那麼，這是超級類型/子類型的東西一個好主意（我懷疑不是）？如果是這樣，有沒有更好的方法去實現它。如果不是，有什麼更好的選擇。

Answer 1

該主題已經在網上進行了廣泛的撰寫。查閱「泛化專業化數據建模」或「泛化專業化數據庫設計」。

就你而言，公司和員工是具有地址的專門實體。

在其他一些情況下，卡車和汽車可能是專用車輛。在另一個案例中，學生和校友可能是專門的社區成員。

我可以在這裏總結一下，但你最好從源頭上獲益。

Answer 2

這個問題有點羅嗦。你可能應該嘗試把它修剪到基本要素。我比JPA更熟悉JPA（在ORM空間中），但JPA有這個概念，它被稱爲映射超類（繼承策略）。這完全有效，值得考慮。

在一個系統中，我設計了許多實體（公司，人員，合夥人，信託等）具有共同實體（例如法定名稱）和相關實體（例如地址，聯繫方式）超類型，這與你要去的地方有些相似。

是的，你確實有一個類型列（在超類型中）。在JPA中稱爲鑑別器列。