在單獨的數據庫表中的人名結構

我想知道何時何時將數據結構拉入單獨的數據庫表中，當它出現在幾個表中。在單獨的數據庫表中的人名結構

我已經將12個屬性地址結構拉到一個單獨的表中，因爲我有幾個不同的實體包含這種格式的單個地址。

但是我的3個屬性人名結構（給定，中間，姓氏）呢？

是否應該將它放入它自己的表中，並用包含名稱的所有實體的外鍵引用......例如，公司桌上有聯繫人姓名，公民桌上有人名等

這些最好留在主表中作爲屬性還是應該提取？

來源

2009-07-22 lox

請注意，我在說的是這些數據結構只能作爲整體的一部分存在，而沒有其他表可以指向同一個實例。 – lox 2009-07-23 07:34:16

我通常會在Person表上保留地址，除非在每個實體上有絕對統一的地址，或者實體可能有任意數量的地址，或者地址需要在實體之間共享，或者如果這是一個大型企業產品，我知道我必須投資全地方的基礎設施，否則我最終會把所有的東西都拆掉。

把你的地址放在一個單獨的表格中很有意思，因爲它很靈活，但是在一個小項目缺乏像上面提到的那樣的特殊需求的情況下，這可能是一個小小的浪費。始終注意複雜性和靈活性之間的平衡。靈活性非常重要，但要區別對待......很容易在這裏投資太多！

具體而言，我嘗試過（例如）地址之類的一對一關係的時代，我最終將它們重構爲表格，因爲它引入了一堆令人頭痛的問題，包括更復雜的查詢，處理地址不存在的情況等等。更多的實體也增加了你的認知負荷 - 這使得項目難以思考。就我而言，這是一筆不必要的成本，因爲沒有具體的需要，事實上，甚至不具有靈活性。因此，根據我的經驗，我會「嘗試」將地址保存在同一個表中，並且我一定會保留這些地址的名稱 - 除非有特殊需要。

所以爲了解釋愛因斯坦，讓它儘可能簡單並且不簡單。但在短期內，實驗。這是學習這些課程的最佳方式。

來源

2009-07-22 13:30:49

這是關於不重複的信息，所以你不想在兩個地方存儲相同的信息。

另一個有用的經驗法則是每個表格一個實體。如果你發現一個表包含「人」和「秩序」，那麼你可能應該把它們分成兩個表。你可能會發現查看一些數據庫設計的基礎知識很有幫助，在這裏有很多關於stackoverflow的相關問題。

開始與這些...

What is normalisation?

What is important to keep in mind when designing a database

How many fields is 'too many'?

More tables or more columns?

來源

2009-07-22 13:12:52

但是，由於新的PersonName錶行被指向外鍵，PersonName信息不會因爲刪除公司行或公民行而消失。然而，它的存在只有通過這些指點行的存在纔是合理的。 – lox 2009-07-22 13:55:34

爲PersonNames打出一張單獨的表是浪費的。 ;）但是如果你這樣做了，你可以使用Cascade Delete，這樣當Person被刪除時，數據庫將刪除相應的PersonName。在SQL Server中，這是關係中的一個選項。 – 2009-07-22 14:05:12

現在，如果PersonName被幾個不同的東西使用 - 比如說PersonNameID 5是Brian MacKay，並且它出現在PersonID 200和CitizenID 120中，那麼您不能再刪除PersonID 200，因爲Cascade會失敗。所以：要麼把人和公民結合成一張桌子，要麼不把名字結構打破成一張桌子，或者兩者兼而有之，簡化你的生活。我建議做兩個。 – 2009-07-22 14:08:35

提取它們。你的目標應該是在你的數據庫中沒有重複的數據。閱讀Normalization

來源

2009-07-22 13:14:14 DanDan

你知道，像名字/姓氏一樣，它不一定重複數據，而是重複數據結構。對我來說，重複這些結構是可以的，只要你不重複數據。在簡單性方面的折衷是值得的。 – 2009-07-22 14:01:27

創建整個數據模型的人實體會給你這個現在和未來的優勢 - 如發生接觸，或在不同背景下個體

同一個人。節省冗餘。
信息可以保持並保持最新狀態。
更容易搜索一個人，並找出他們 - 即它是否是相同的約翰史密斯？
您可以擴展信息 - 即爲此人更方便地維護地址。
編程將更加一致，調試也將變得更加容易。
讓您更接近'自我記錄'系統。

來源

2009-07-22 13:20:46 blispr

這實際上取決於你正試圖解決的問題。一般來說，擁有某種「人物」表格可能是一個好主意，它保存着人們的細節。但是，在某些情況下，這可能是一個非常糟糕的主意。

例如，如果您持有由醫生向人們寫出的處方的詳細信息。在一些國家，這是一個法律要求，規定的詳細信息是與他們的名字，而不是他們目前的名字。例如，一名婦女可能被開處方爲X小姐，但她隨後結婚併成爲Y夫人。如果您有一張與處方表相關的人桌，您現在將會看到錯誤的細節，並可能面臨法律後果。在這種情況下，您可能需要將該人員的相關詳細信息複製到處方表中，即使這可能會複製數據。

所以再次 - 這取決於你正試圖解決的問題。不要盲目追隨人們認爲的最佳實踐。瞭解您的數據及其相關問題，然後嘗試遵循適合的最佳做法。

來源

2009-07-22 13:30:12

作爲與其他（完全有效）答覆的對應點：在您的應用程序的當前結構中，對於給定的個人（不只是名稱，實際「人員」 - 多個人可能是「John Smith 「）出現在多個表中？這種情況發生的可能性越小，從正常化中獲益的可能性就越小。

另一種想法是實體。在標籤（名稱）之外，它們是否在「客戶」實體和「員工」實體之間有重疊？

來源

2009-07-22 13:30:59

取決於您使用的數據庫。

如果你想在你的表上進行快速查詢，你應該對你的表進行反規範化處理。必須運行多個JOIN將需要更長的時間，並且使查詢更加複雜。另一方面，如果你的目標是要有一個靈活的存儲數據庫，並不意味着大量的快速響應查詢，那麼通過將這些表分割成多個xref表格來規範化表格將提供設計更靈活，並減少提交重複數據的需求。

由於解除歸一化爲「優化」，因此我建議您先對錶格進行歸一化處理，正確編制索引並查看是否在查詢中遇到任何瓶頸。如果是這樣，在需要的地方平整受影響的表格。

來源

2009-07-22 13:44:07 ascotan