MySQL：多個表還是一個包含許多列的表？

Question

所以這更像是一個設計問題。

我有一個主鍵（比如用戶的ID），我有大量與該用戶相關的信息。

我應該根據信息將多個表分解為類別，還是應該只有一個包含多列的表？

我以前的方式是擁有多個表，例如，一個表用於應用程序使用數據，一個表用於配置文件信息，一個表用於后端令牌等，以使事情看起來井井有條。

最近有人告訴我，最好不要這樣做，並且有一個包含大量列的表是好的。 問題是，所有這些列都具有相同的主鍵。

我對數據庫設計很陌生，所以哪種方法更好，哪些是優點和缺點？

這樣做的傳統方式是什么？

Answer 1

任何時候信息都是一對一的（每個用戶都有一個名稱和密碼），那么最好有一個表，因為它減少了數據庫檢索結果所需的連接數。 我認為有些數據庫對每個表的列數有限制，但在正常情況下我不擔心它，如果需要，你可以隨后將其拆分。

如果數據是一對多（每個用戶有數千行使用信息），那么它應該拆分成單獨的表以減少重復數據（重復數據浪費存儲空間，緩存空間，並使數據庫更難維護）。

您可能會發現Wikipedia關於數據庫規范化的文章很有趣，因為它深入討論了這個原因：

數據庫規范化是組織關系數據庫的字段和表以最小化冗余和依賴性的過程。 規范化通常涉及將大表分成較小（和較少冗余）的表並定義它們之間的關系。 目標是隔離數據，以便可以在一個表中進行字段的添加，刪除和修改，然后通過定義的關系傳播通過數據庫的其余部分。

非規范化也需要注意，因為有些情況下重復數據更好（因為它減少了數據庫在讀取數據時需要完成的工作量）。 我強烈建議您盡可能將數據標准化，並且只有在了解特定查詢中的性能問題時才進行非規范化。

Answer 2

一張大桌往往是一個糟糕的選擇。 相關表是關系數據庫的設計用途。 如果您正確索引並知道如何編寫高性能查詢，那么它們將表現良好。

當表格列太多時，您可能會遇到數據庫存儲信息的頁面的實際大小問題。 記錄最終可能對於頁面來說太大，在這種情況下，您可能最終無法創建或更新使用戶不滿意的特定記錄，或者您可能（至少在SQL Server中）允許某些特定溢出數據類型（如果您正在執行此操作，則需要查看一組規則）但如果許多記錄將溢出頁面大小，則可能會產生棘手的性能問題。 現在，MYSQL如何處理頁面以及當潛在頁面大小過大時是否有問題是您必須在該數據庫的文檔中查找的內容。

Answer 3

我有一個很好的例子。 過度規范化的數據庫，具有以下一組關系：

people -> rel_p2staff -> staff

和

people -> rel_p2prosp -> prospects

在人們有姓名和人員詳細信息的地方，工作人員只有員工記錄詳細信息，前景只有潛在客戶詳細信息，而rel表是與人員鏈接到工作人員和潛在客戶的外鍵關系表。

這種設計對整個數據庫進行。

現在要查詢這組關系，它每次都是一個多表連接，有時候會加入8個表。 它已經在今年年中很好地工作，當它開始變得非常緩慢，因為我們已經超過40000人的記錄。

索引和所有低掛水果去年已經用完，所有查詢都經過優化以達到完美。 這是特定規范化設計和管理的道路的終點，現在批准了整個應用程序的重建，該應用程序依賴於它以及數據庫的重組，為期6個月。 哎喲。

解決方案將是與people -> staff和people -> prospect有直接關系

Answer 4

碰到這個，並且作為曾經使用過MySQL的人，最近切換到Postgres，其中一個很大的好處就是你可以將JSON對象添加到Postgres的一個字段中。

因此，如果你處於這種情況，你不必在一個包含許多列的大表之間做出決定並將其拆分，但你可以將列合並到JSON對象中以減少它，例如，而不是地址為5列，它可以只是是一個。 您也可以查詢該對象。

Answer 5

如果你把所有東西都放在一個表中，那么你會問自己這些問題嗎？你會為這個用戶設置多行嗎？ 如果必須更新用戶，是否要保留審計跟蹤？ 用戶可以擁有多個數據元素實例嗎？ （比如電話號碼）您是否會想要稍后添加元素或元素集？ 如果您回答是，則很可能您希望擁有具有外鍵關系的子表。

父/子表的優點是數據完整性，通過索引的性能（是的，您也可以在平面表上執行），如果您需要稍后添加字段，IMO更容易維護，特別是如果它將是必填字段。

設計設計更難，查詢變得稍微復雜一些

但是，在許多情況下，一個大的平台是合適的，所以你必須看看你的情況來決定。

Answer 6

我已經完成了某種數據庫設計。 對我來說，這取決於系統與數據庫管理的難度; 是的，只在一個地方擁有獨特的數據是真的，但是對於具有大量記錄的過度規范化的數據庫來說真的很難進行查詢。 只需結合兩個架構; 如果你覺得你將擁有像facebook，gmail等那樣難以維護的大量記錄，請使用一張巨大的桌子。 並使用不同的表為一套簡單的系統記錄...這只是我的意見..我希望它可以幫助..只是做它..你可以做到這一點...... :)

Answer 7

執行此操作的傳統方法是使用星形模式或雪花模式中的不同表。 Howeevr，我將這個策略基於兩倍。 我相信數據應該只存在於一個地方的理論，因為我提到的模式運作良好。 但是，我也相信，對於報告引擎和BI套件，柱狀方法將非常有益，因為它更能支持報告需求。 像infobright.org那樣的柱狀方法具有巨大的性能提升和壓縮，這使得使用這兩種方法非常有用。 很多公司開始意識到組織中只有一個數據庫架構並不能滿足他們的全部需求。 很多公司正在實施具有多個數據庫架構的概念。

Answer 8

我認為擁有一個表更有效但你應該確保表的組織方式能夠顯示同一行的關系，趨勢以及變量的差異。 例如，如果表格顯示了學生的年齡和成績，那么您應該以一種方式對表格進行排序，使得最高分的得分者與最低得分者的差異很大，而且學生年齡的差異是均勻的。