我有一個數據庫，它將存儲關於個人的配置文件。這些人有大約50個可能的領域。什麼更好 - 許多小桌子或一張大桌子？
一些常見的事情，如名字，姓氏，電子郵件，電話號碼。
其他事情一樣的愛好，技能，興趣
有些是身高，體重，皮膚的顏色。
這些組中的每個組都由系統在不同的時間使用。就能夠通過數據庫進行談判而言，我傾向於每個約8個字段有7個表格。最佳做法是什麼？
編輯：該數據將用於搜索引擎，用於查找配置文件匹配。這會影響我在做什麼嗎？
這很難說，而且是基於應用程序的要求。我會說，看看Database Normalization，因爲它會告訴你如何規範化數據庫，它應該闡明你想分離出他們自己的表格等。
這個問題沒有正確的答案因爲它很大程度上取決於何時以及如何使用數據，數據的更改頻率以及數據庫的使用量。
我個人的做法是將數據組織到邏輯實體中，並根據這些實體創建表。這至少是我要開始的地方。
我不會擔心使用量與數據質量一樣多。 – 2010-11-03 17:43:44
許多小表即標準化在這裏最好。它提供了靈活性，減少冗餘和更好的數據庫組織。
從你所描述的我肯定會把它分成多個表。我不會在任意數量的列上分割，而是嘗試考慮組成實體的列的邏輯集合，或者匹配您要用來訪問數據的訪問模式
是的，這個數字僅僅是一個例子，數據將被語義分組。 – Ash 2010-11-03 17:48:45
有不是100％正確的數據庫組織，只有一個足夠滿足您的需求。如果您未來預計未超越單個優質數據庫服務器的功能，那麼將數據規範化並使用大量限制，例如外鍵，級聯刪除等，這將使您的數據庫處理起來更加愉快。另一方面，如果您查看許多具有數十億請求的應用程序的數據庫，則會發現它們以性能和可伸縮性爲名放棄了許多這些細節。
您是我第一個聽到的人說「級聯刪除是與我一起工作的快樂」 – 2010-11-03 17:42:27
IMO，更重要的是擔心所存儲數據的質量，而不是您需要的表的數量。
例如，您是否需要跟蹤更改？如果約翰在2007年1月爲5英尺2英寸，2010年10月爲5英尺11英寸，你想知道嗎？如果是這樣，你需要把這個人從高度分成兩個表格。
愛好如何 - 他們只允許有3種愛好嗎？他們可以有更多/更少？這是你將來想要查詢的東西嗎？如果是這樣，你需要一個單獨的表。
您應該閱讀數據庫設計和規範化（本網站上有幾個優秀的線程）。
除非每個人都擁有相同數量的愛好（IE每個人都有2周所列的愛好），應該歸。
與該人總是1對1的字段應位於同一個表中。年齡例如。沒有人會有兩個不同的年齡。
我會推薦幾張桌子。過度規範化很難管理，最終你會寫出複雜的查詢，最終導致性能下降。
只有在絕對需要時才進行標準化，並按邏輯方式進行思考。隨着你在上面提供的信息有限，我會去三個表：
表1： PersonalDetails 表2：活動 表3：其他
還有其他一些技術來加快性能如羣集等，您可以根據您的需要使用。
我與Normalize營地。
下面是一些提示，讓你開始：
開始與過程的一些任意的唯一標識符分配給每個 「人」。稱之爲PersonId或類似的東西。這個標識符被稱爲 代理鍵。代理鍵的唯一目的是 保證它與真實世界中的真人之間的1對1關係。將 某個其他屬性的值與 數據庫中的「人員」相關聯時，使用代理鍵 。
在開發數據庫佈局時，您可能會發現其他一些屬性也需要代理鍵（或至少有用） 。
看看你想管理的每個屬性。詢問以下問題： 任何給定的人對於此屬性只有一個值？
例如，每個人 只有一個「出生日期」。但他們有什麼「興趣愛好」？可能是零到很多。 單值屬性（例如出生日期，身高，體重等）是以PersonId爲關鍵字進入 公用表的候選人。在這一點上，每個表中屬性的數量不應該是 。
多值屬性如Hobby需要稍微不同的 處理。您可能需要爲每個多值屬性創建單獨的表。使用Hobbies作爲 示例，您可以創建以下表PersonHobby(PersonId, Hobby)。此表中的一行可能看起來像 ，如：(123, "Stamp Collecting")。這樣，您可以按照每個人的要求記錄儘可能多的業餘愛好，每行一個。爲「興趣」，「技能」等做同樣的事情
如果有相當數量的多值屬性 其中PersonId + Hobby組合確定沒有其他的（即你沒有什麼有趣的 來記錄這個人做這個「業餘愛好」或「興趣」或「技能」），你可以將它們包含到 屬性值表中，該表的結構類似於PersonAV(PersonId, AttributeName, Value)。這裏一行可能 看起來像：(123, "Hobby", "Stamp Collecting")。
如果你走這條路線，它也是替代 的AttributeName在PersonAV表的代理鍵，然後再創建表涉及此 關鍵其描述一個好主意。 類似於：Attribute(AttributeId, AttributeName)。此表中的一行看起來像 (1, "Hobby")和對應的PersonAV行可能是(123, 1, "Stamp Collecting")。這通常是 ，因此如果您需要知道哪個AttributeNames在您的數據庫/應用程序 中有效，那麼您有一個地方可以查看它們。考慮如何驗證「興趣」是否是 AttributeName的有效值 - 如果您沒有記錄某人擁有該AttributeName那麼 對您的數據庫沒有該AttributeName的記錄 - 您怎麼知道它是否是它應該存在與否？那麼請在Attribute表中查找！
某些屬性可能有多個關係，這也會影響表的規格化。我沒有 在您的示例中看到這些依賴關係中的任何一個，因此請考慮以下事項：假設我們有一個倉庫 裝滿零件，PartId確定它的WeightClass,StockCount和ShipCost。這建議表 類似於：Part(PartId, WeightClass, StockCount, ShipCost)。但是，如果 非關鍵屬性之間存在關係，則應將其分解出來。例如假設WeightClass直接 確定ShipCost。這意味着僅WeightClass就足以確定ShipCost和ShipCost應該從Part表中分解出來。
標準化是一個相當微妙的藝術。您需要確定數據模型中所有屬性之間存在的功能依賴關係 ，以便正確執行。只需要 提出的功能依賴需要一定的思想和考慮 - 但它是 是進行正確的數據庫設計的關鍵。
我建議您在構建數據庫之前多花點時間到 研究規範化。在這裏花費了幾天的時間，其餘的花費將超過本錢。嘗試做一些谷歌/維基百科搜索 「功能依賴」，「規範化」和「數據庫設計」。閱讀，學習，學習，然後建立它的權利。
我對數據庫設計規範化提出的建議只是提示您可能需要採取的方向。如果您沒有很好地掌握您在應用程序中試圖管理的所有數據，那麼在此提供的任何建議都應該以「一粒鹽」來進行。
用於標準化的+1 – 2010-11-03 17:41:40
該數據將被用於搜索引擎中，用於查找配置文件匹配。這會影響我在做什麼嗎？ – Ash 2010-11-03 17:50:19
如果您將從RDBMS中檢索，那麼請正常化。它會以積極的方式影響您的工作 – Randy 2010-11-04 20:37:57