NHibnerate數據設計建議

Question

在對一對一關系進行映射的研究中，我遇到了一些讓我質疑我的數據庫設計決策的陳述。

基本上我有一些類似於以下的實體：

人，聯系人，父母

聯系人和父母都是人。 一個人可以是聯系人，父母，兩者或兩者。

我想出的數據庫設計為這三個實體中的每一個都有一個表，並且所有三個表共享一個主ID（PersonID）。 從數據庫設計的角度來看，這似乎是一種表示數據庫及其關系的良好規范化且合理的方式（至少對我而言）。

此時，我開始編寫C＃類和NHibnerate映射來表示這些實體。 我能找到的最自然的映射方法是使用映射。 其他選項（一對一，一對多等等）似乎要求我向表中添加一個或多個不必要的FK。 在瀏覽NHibernate文檔后，我偶然發現了以下聲明：

此功能通常僅對遺留數據模型有用，我們建議使用的表少於類和細粒度域模型。 但是，如下所述，在單個層次結構中切換繼承映射策略很有用。

我的問題是：

A）我違反了這個原則嗎？ B）如果是這樣，我該如何更好地設計這個系統？

這個陳述是否表明我應該將所有Person / Contact / Parent字段整合到一個表中（有許多可空字段）？ 還是我不知何故錯過了這一點？

由於這是一個罕見的場合，我可以從頭開始設計表/類，我希望能夠做到。 先謝謝您的幫助！

編輯：有關我打算如何使用上述數據庫設計的更多信息：

基本的想法是每個人都在人員表中獲得記錄。 相關表中是否存在記錄確定該人是父母，聯系人等......這似乎強制執行一對一關系並允許快速查詢/加入（共享主ID將是一個每個表中的聚集PK）。

編輯：謝謝你的幫助。 當我設計這個系統時，我並沒有真正考慮可查詢性，所以我將轉向類似於Jamie Ide和hlgem建議的解決方案。 我發現所有答案都有幫助。 總而言之，它看起來像共享主鍵導致c＃端的對象模型出現一些問題。

Answer 1

您的數據庫設計需要一些工作; 這是我的建議。

你知道聯系人和家長都可以成為人，這是很好的。 但是，您需要Contact和Parent才能擁有不同的主鍵。 您可以強制要求它們在Contact表和Parent表中都具有帶有非可空外鍵的父ID，該表引用Person表中條目的Person ID。

因此Person表應具有唯一的主鍵（其ID）和任何其他相關列。 Contact表應具有自己唯一的主鍵（其ID），對Person表的不可為空的外鍵引用（Person表中的ID）以及任何其他相關列。 Parent表應具有其自己的唯一主鍵（其ID），以及對Person表（Person表中的ID）和任何其他相關列的不可空外鍵引用。

這應該可以解決您的映射問題。 如果需要，您可以使用View來“重新組合”您的Person / Parent / Contact“constellation”（相關表的集合）。

Answer 2

你問的是繼承映射，而不是一對一的關系。 您的設計需要每子類表映射，但我不確定如何解決Person可以同時是Contact和Parent的要求。 除了介紹另一個涵蓋這兩個角色的子類之外，我不知道對此進行建模的好方法。 可以這樣想，如果你要求你的存儲庫返回一個Person，那個Person既是Contact又是Parent，它應返回哪種類型？

如果您堅持繼承子類，那么我建議如果可能的話堅持每個表 。

但更好的設計可能是引入“角色”表，並在人與角色之間建立一對多的關系。

編輯添加：恕我直言，您當前的設計將無法正常工作。 什么類型的對象代表同時是聯系人和父母的人？

您可以使用包含其他數據的“復雜”角色表，而不是簡單的角色表。 您可以擁有一組Role對象（ContactRole，ParentRole等），每個對象都包含與該角色關聯的字段。 然后，Person對象將具有Role對象的集合。

Answer 3

其中一些取決於您打算如何查詢該數據。 如果您希望能夠輕松地查看某個人在角色特定的詳細信息中扮演的角色，那么請擁有角色表。 要查看一個人擁有的所有角色，無論您稍后添加多少個角色，都只需要連接兩個表。 否則，您將必須加入每個專業表（如果不存在，則為左聯接），只是為了查看一個人有什么角色。 表現不太好。

我們在數據庫中有很多這種類型的關系，我們有一個帶有id的person表，一個帶有id和角色id的角色表，以及一個角色類表，它是角色的查找。 然后是具有特定角色信息的專業表，例如銷售代表或銷售目標。 每個表都有自己的id，每個表（查詢表除外）都包含來自person表的id，該id被設置為外鍵。 （相信我很少有這樣的東西，比如不必要的外鍵，反之亦然，錯過FK，當你應該有一個是壞消息時。）

現在你仍然可以使用父表中的PK作為Fk到person表和專業表的PK，但我建議不要使用外鍵關系。 無論如何，如果您沒有在人員表中設置FK，那么您的數據注定會導致數據完整性問題。 我更喜歡使用代理鍵，因此總是在每個表上設置我自己的鍵。 從長遠來看，它可以防止許多重新設計問題。 如果要保持一對一的關系，就可以在該字段上使用簡單的唯一索引。 該表從一對一移動到一對多，您需要做的就是刪除索引。 如果你也使用它作為你的PK，那么你需要一個新的PK，所有引用pk的代碼都必須改變。 將新PK添加到包含150,000,000條記錄的表中，而不是一項有趣的任務。