在做一些映射一對一關係的研究時,我遇到了一些讓我質疑我的一些數據庫設計決策的陳述。NHibnerate數據設計建議
基本上我有類似以下一些實體:
人聯繫,家長
兩個觸點和父母都是人。 一個人可能是聯繫人,父母,兩者都不是。
我想出的數據庫設計爲這三個實體中的每一個都有一個表,並且所有三個表共享一個主ID(PersonID)。從數據庫設計的角度來看,這似乎是一種很好的規範化和合理的表現方式來表示數據庫及其關係(至少對我而言)。
此時,我開始編碼C#類和NHibnerate映射來表示這些實體。我能找到的最自然的映射方法是使用映射。其他選項(一對一,一對多等)似乎要求我在表中添加一個或多個不必要的FK。在通過NHibernate的文檔瀏覽我偶然發現瞭如下聲明:
此功能常常對遺留數據模型有用,我們推薦比類和細粒度的領域模型表少。但是,如稍後所解釋的,在單個層次結構中的繼承映射策略之間進行切換非常有用。
我的問題是:
A)我是不是違反本校長? B)如果是這樣,我會如何更好地設計這個系統?
這段陳述是否暗示我應該將所有Person/Contact/Parent字段合併到一個表中(帶有許多可爲空的字段)?或者我不知何故錯過了這一點?
由於這是一個罕見的場合,我可以從頭開始設計表格/類,所以我想說得對。先謝謝您的幫助!
編輯:我是如何打算的上述數據庫設計更多信息工作:
的基本思路是,每個人得到的人表中的記錄。相關表中記錄的存在/不存在決定了這個人是否是家長,聯繫人等......這似乎強制執行一對多關係並允許快速查詢/連接(共享主ID是在每個表中聚集PK)。
編輯:謝謝你們的幫助。當我設計這個系統時,我並沒有真正考慮到查詢能力,所以我將轉向類似於Jamie Ide & hlgem建議的解決方案。我發現所有的答案有幫助。總而言之,共享主鍵看起來會導致c#端的對象模型出現一些問題。
謝謝你的建議。我同意這會解決我的映射問題。但是,我認爲這使得數據庫設計方面「更醜陋」。由於所有這些關係都應該是一對一的(也許我應該在第一篇文章中明確說明),您的建議似乎會在模型中引入大量不必要的FK。除此之外,它使關係成爲一個>多個而不是一個>一個 - 最初的設計會強制執行正確的基數。 – Krazzy 2010-01-25 19:23:53
@Krazzy:說實話,在不瞭解表格範圍的情況下建議設計有點困難;因爲我不知道Person,Parent和Contact有多少列,所以很難說出什麼是好的設計。根據您的反饋,也許您最好將Parent和Contact表與Person表合併,並根據需要使用View來恢復父級和聯繫人? (這基本上是我原來的建議的反面...) – 2010-01-25 20:39:43
@Krayzzy:無論如何,基本問題是共享主鍵。一個很好的通用規則(以及Hibernate廣泛使用的規則)是爲每個表都有一個不同的主鍵。 – 2010-01-25 20:41:04