TA貢獻1825條經驗 獲得超6個贊
任何時候信息都是一對一的（每個用戶都有一個用戶名和密碼），那么最好在一個表中使用它，因為它減少了數據庫檢索結果所需的聯接數。我認為某些數據庫對每個表的列數有限制，但是在正常情況下我不會擔心它，如果需要，您可以隨時將其拆分。
如果數據是一對多的（每個用戶有數千行使用情況信息），則應將其拆分為單獨的表以減少重復的數據（重復的數據會浪費存儲空間，緩存空間，并使數據庫難以維護）。
您可能會發現有關數據庫規范化的Wikipedia文章很有趣，因為它深入討論了這樣做的原因：
數據庫規范化是組織關系數據庫的字段和表以最小化冗余和依賴性的過程。規范化通常涉及將大表劃分為較?。ê洼^少冗余）的表，并定義它們之間的關系。目的是隔離數據，以便可以僅在一個表中進行字段的添加，刪除和修改，然后通過定義的關系傳播到數據庫的其余部分。
還需要注意非規范化，因為在某些情況下重復數據會更好（因為它減少了數據庫讀取數據時需要做的工作量）。我強烈建議您盡可能使數據規范化，以便開始使用，并且只有在您意識到特定查詢中的性能問題時才進行非規范化。
TA貢獻1780條經驗 獲得超4個贊
一個大桌子通常是一個糟糕的選擇。相關表是設計用于關系數據庫的對象。如果您正確地建立索引并且知道如何編寫性能查詢，它們將表現良好。
當表中的列過多時，您可能會遇到數據庫在其上存儲信息的頁面實際大小的問題。記錄可能最終對于頁面而言太大，從而可能導致您最終無法創建或更新特定記錄而使用戶不滿意，或者您（至少在SQL Server中）可能因某些原因而溢出數據類型（如果要執行此操作，則需要查找一組規則），但是如果許多記錄將使頁面大小溢出，則會造成嚴重的性能問題?，F在，MYSQL如何處理頁面以及潛在頁面大小過大時是否有問題，您需要在該數據庫的文檔中查找。
TA貢獻1793條經驗 獲得超6個贊
我有一個很好的例子。具有以下一組關系的過度標準化的數據庫：
people -> rel_p2staff -> staff
和
people -> rel_p2prosp -> prospects
在人員具有姓名和人員詳細信息的地方，人員僅具有人員記錄的詳細信息，潛在客戶僅具有潛在客戶的詳細信息，而rel表是關系表，其中包含來自與人員和潛在人員鏈接的人員的外鍵。
這種設計針對整個數據庫進行。
現在要查詢這組關系，每次都是一個多表聯接，有時是8個或更多表聯接。到今年年中，它的運行情況一直很好，當時它開始變得非常緩慢，現在我們已經超過了40000條記錄。
索引和所有低落的成果已于去年用完，所有查詢都經過優化以達到完美。這是特定標準化設計的道路的盡頭，現在，管理人員批準了對依賴于該應用程序的整個應用程序的重建以及數據庫的重建，歷時6個月。$$$$哎呀。
解決方案將是people -> staff與people -> prospect
舉報