我注意到很多人在這裏引用了一張表中有20+（我見過多達55）列的表格。現在我不假裝成爲數據庫設計專家，但我一直聽說這是一種可怕的做法。當我看到這一點時，我通常建議將它們分成兩個表，一對一的關係：一個包含最常用的數據，另一個包含最少使用的數據。雖然在同一時間，可能存在性能問題（少JOINs等）。所以我的問題是這樣的：有多少列是太多列？
當涉及到真正大規模的數據庫時，實際上有大量列的優點，儘管這通常會導致很多NULL值？
哪種性能更好：大量的NULL列很多，或者列數較少的JOIN？
表的設計取決於它需要存儲的實體。如果所有的數據都歸屬於一起，則50列（甚至100列）可能是正確的。
只要表格是normalized，除了數據庫功能和需要優化之外，關於大小沒有經驗法則。
我同意Oded。我看過有500列的桌子，其中的所有列都在正確的位置。只要考慮一下人們可能希望存儲的關於日常物體的事實數量，你很快就會明白爲什麼。
如果證明不方便選擇所有這些列，或者指定當您只對其中的一小部分感興趣時選擇哪些列，則可能會發現值得定義一個視圖。
哪個更性能命中： 大量列有很多空值的，或者有很多的JOIN的 較少的列？
它完全取決於您存儲的數據，您創建的索引等。沒有人能確保你在不知道你在儲存什麼的情況下比另一個更好。一般來說，規範化規則將「強制」你將數據分離到不同的表和用戶FKeys，如果你有大表，但我不同意它總是比一個大表表現更好。您可以在數十個查詢中以6-7級別連接結束，這些查詢有時會導致錯誤，因爲在大型查詢中創建錯誤的機會大大增加。
如果您發佈了一些您正在做的事情，也許我們可以幫助您正確設計數據庫。
odbc的字符數限制爲8000 ....所以這是一個物理限制，超出這個限制會讓事情變得非常令人沮喪。
我在一張有138列的表格上工作過，它寫得很糟糕，可能已經正常化了。雖然這個數據庫似乎是某人想知道爲什麼數據庫設計中有約定，並決定一次測試它們。
當您進入數據倉庫和報表服務器時，具有非常寬的平整表格是相當常見的。它們速度更快，意味着您不必將數據庫存儲在內存中以獲得性能。
有多少列是太多列？
當你覺得它不再有意義或者是正確的添加另一列。
一般取決於應用。
根據我的經驗，最好減少連接數，因爲這些連接往往發生得太頻繁，特別是在大型數據庫中。只要你的數據庫表被設計爲存儲單個實體（學生，老師等），這應該是沒問題的。因此，這將在稍後的代碼中作爲對象表示。所以，如果你將實體分成幾個表，你將不得不使用幾個連接來填充你的對象。此外，如果您使用ORM生成數據訪問層（如.Net中的Linq），將爲每個表生成單獨的類（當然，它們之間存在關係但仍然存在），並且這將很難使用。
另一件事是，您可以指定要在您的查詢中返回哪些列，這將減少傳遞給您的應用程序的數據，但是如果您需要從另一個表中獲得單個列，則必須執行連接。而且在大多數情況下，因爲您有很多列，那麼在數據庫中存儲大量數據的概率很高。所以這個連接會比NULL更有害。
我所從事的每個項目都不同，因此您應該爲每個故事找到平衡點。
非常真實。顯然，聯接和多選查詢很慢，因此應儘可能考慮非規範化，而不會像您所建議的那樣破壞一致性。 – JCasso 2017-09-27 15:49:51
它也高度依賴於您的表的用例。如果你想優化它的閱讀，那麼把它放在一張表中可能是一個好主意。
在NO-SQL世界（例如cassandra/hbase）中，對列的數量沒有限制，實際上有很多列是一個很好的做法。這也來自它存儲的方式（沒有差距）。值得一邊調查。
最好使用單個表，避免在查詢時使用連接，這取決於列是相同的實體還是不同的實體。
例如，假設您正在爲工作流進行數據庫設計，其中一些字段將由初級工作人員編輯，一些字段由高級工作人員編輯。在這種情況下，最好將所有列放在一個表中。
-1：_why_是更好嗎？ _哪種方式更好？ – 2014-05-30 07:21:15
如果列太多，會導致很多空值（邪惡）以及該表映射到的難以操作的對象。這會影響IDE的可讀性並妨礙維護（增加開發成本）。如果在某些情況下需要快速讀取，請使用非規格化表格僅用於報告或查詢（搜索「CQRS」模式）。是「人」有一百萬個屬性，但是您可以分解這些單一表（設計優先於標準化）以匹配較小的實體（「地址」，「電話」，「業餘愛好」），而不是爲每個新用例添加新列。具有較小尺寸的物體（和桌子）帶來如此多的優點;他們可以實現單元測試，OOP和SOLID實踐等功能。另外，因爲它涉及聚集許多列以避免連接，所以我認爲，通過索引維護，假設典型的讀寫工作負載，避免連接帶來的性能收益會丟失。爲了讀取性能而在字段上添加索引可能表示需要將這些字段移動到它們自己的表中。
看起來很明顯，它完全取決於數據庫的要求以及每個操作在其上執行的重要程度。感謝您的答案。 – 2010-07-06 08:34:12