如果我有一個客戶表，它將存儲姓名，地址，電子郵件地址，電話號碼，甚至對客戶，如年齡，喜好等一些細節幾個數據庫設計問題
請問我是如果我把它分成更小的表格，做一件好事情？例如。 customer_contact與聯繫人字段，並在原始Customer表中留下姓名，出生日期等。
此外，通過查找表，它們只是從單獨表格到一個大表格的字段的組合，對吧？
此外，在我自己的系統中，我有一張表格代表產品，但它只有一個ID。此表的唯一字段是適用於許多產品的字段/屬性（如果它是道路合法的），並且這是另一個表的字段，所以兩個表之間存在約束（關係）。我會假設一個查找表將合併這兩個表在一起，對吧？
謝謝
這取決於。
的customer_contacts表將是使用當不存在具有對於每個顧客接觸的行的多個（未知）號的可能性。另一方面，如果您確信每個客戶有3個聯繫方式，則可以將其存儲在與客戶相同的表中。
在大多數情況下，分解通常更好。當然在你列出的所有東西的情況下。
試想想，你的數據庫設計像像Java，其中複雜的對象鏈接語言的面向對象的程序。任何可能與你的實體「連接」的東西，特別是如果它可以鏈接到多個實體，可能是一個候選對象，因此是一個表。
爲主客戶表提供關於識別他的個人核心信息，如您所建議的那樣。
然後所有其他元數據和輔助數據可以綁定到它。例如，地址或電話號碼或電子郵件是很好的對象候選人應該擁有自己的表格，尤其是因爲他們可能具有其他屬性。然後，另一個表格可以將地址與客戶相關聯（例如，如果您的整個家庭正在使用您的系統）。
一般來說，如果你有大量的列（在這種情況下，重新設計可能是有序的），或者如果你對不同的數據有不同的SECURITY要求，你只會（垂直）分區表（SSN或工資數據與正常數據分開）。
當你說「lookup table」時，我想你實際上是指「外鍵」。如果您有一張保存產品可用性的表格，則每行都有一個產品ID，該產品ID指向所有其他產品信息。
通常，術語查找表被過度使用。如果您再次從標準編程的角度來思考，查找表就相當於使用常量來引用幻數或常量對象。
因此，您對另一個通常爲原子的實體使用唯一標識符，因爲它不包含其他對象（例如狀態，地址，產品詳細信息等）。在覈心表中，您將擁有該ID而不是實際的詳細信息。
如果一張表引用了一箇中央實體，最好用關係而不是查找表來思考。
我認爲數據庫設計都是關於平衡和判斷。如果您看不到數據庫變得非常大，則將其歸一化。如果你可以看到它變得相當大，那麼恕我直言就會阻止正常化，除非它的必要IE不使用映射表，無論任何人說扁平數據庫運行得更快。
我會將地址存儲在同一個表格中，除非您覺得客戶端有可能需要地址歷史記錄或單獨的結算地址和送貨地址。我永遠不會破壞聯絡細節和生日，因爲他們不是真正的重點。
我使用查找表像枚舉，事實上他們大多數成爲枚舉。
每個人對數據庫的設計有自己的想法......
這是一個有點平衡的行爲的，其在一個表中所有的列（非規格化）將導致更少的連接和更好的性能，但如果你以後需要改變的話，將會是一種痛苦。作爲Uri mentioned，從OOP角度考慮您的數據庫設計將幫助您確定哪些表應該是獨立的。我強烈建議學習如何放置一個簡單的Entity-Relationship Diagram。這將允許您繪製出您的數據庫設計，並計算出在執行過程中如何將所有內容鏈接在一起。
你在問正確的問題。將數據劃分爲可重用表格的概念稱爲「規範化」。典型的客戶關係經理（CRM）系統有一些表格，如電話，地址，人員......非常普遍的表格，可以用於各種目的。
例如，電話和地址可以用來不僅爲客戶，但對於貨主，供應商，員工等
一旦你有一個基本的結構，你就可以開始連接到客戶的地址和電話。請記住，每位客戶都可以擁有ShippingAddress，BillingAddress，HomePhone，BillingPhone，MobilePhone等。您將創建諸如CustomerAddress和CustomerPhone之類的表格，以便將客戶與其各自的信息進行匹配。
有人比我曾經說過更爲明智：「正常化，直到它傷害，反規範化，直到它的工作原理」
這是明智的，打破了長錶轉換爲通過一對一的關係，加入小語義塊。然後你可以通過視圖給他們打電話。甚至很多ORM都是友好的查看
但是，如果數據庫獲得很多匹配，這些額外的連接將會傷害到您，就像在Web或Intranet情形中那樣。
如果你想讓你的表在高壓力情況下分開，你可能想要使用一個骯髒而醜陋的作弊，在許多公共web項目中使用，並通過在主表上委派一列來存儲虛擬視圖集合中的相關數據。