有多少個數據庫表列太多？

我已經接管了具有超過30列的用戶表的項目的開發。不好的一面在於列的更改和添加不斷髮生。有多少個數據庫表列太多？

這是不對的。

我是否應該將額外的字段作爲值移動到第二個表中，並創建存儲這些列名的第三個表？

user 
    id 
    email 

user_field 
    id 
    name 

user_value 
    id 
    user_field_id 
    user_id 
    value

來源

2010-12-16 Xeoncross

一句話，NO！ – HLGEM 2010-12-17 22:30:05

做不是去鍵/值路線。 SQL不是爲了處理它而設計的，它會讓你從數據庫中獲取實際的數據來進行自我折磨。（例子：索引不能很好地工作，當你不得不加入以獲取你加入的數據時，聯接很有意思）它繼續。

只要數據被歸一化爲一個體面級別你沒有太多的列。

編輯：要清楚，有一些問題只能通過鍵/值路線來解決。「太多列」不是其中之一。

來源

2010-12-16 19:38:05 Donnie

+1。將字段名稱放在一個單獨的表格中會使您的工作變得非常困難。 – matt 2010-12-16 19:40:25

是的，我想努力使所有的值的請求將是一個痛苦，如果它們移動到其他錶行。 – Xeoncross 2010-12-16 20:03:07

這真的取決於你想做什麼。

來源

2010-12-16 19:37:34

很難說有多少是太多。這真的很主觀。我認爲你應該問的問題不是「是否有太多的專欄？」，而是「這些專欄是否屬於這裏？」我的意思是，如果用戶表中有列不一定是用戶的屬性，那麼它們可能不屬於。例如，如果你有一堆總結用戶地址的列，那麼你可能會將這些地址列表放入一個帶有FK的地址表中。

如果可能的話，我會避免使用鍵/值表。它可能看起來像一個簡單的方法來使事物可擴展，但從長遠來看這真的只是一個痛苦。如果您發現模式的變化非常一致，您可能需要考慮設置某種變更控制，以僅對必要變更進行審覈，或者遷移到另一種更好地支持無模式存儲的技術，如使用MongoDB的NoSQL或CouchDB的。

來源

2010-12-16 19:38:12 dustyburwell

我懷疑是否在此應用程序大部分的東西是必要的。但是，再次，我只是一個僱傭的程序員。 – Xeoncross 2010-12-16 20:03:56

這通常被稱爲EAV，以及這是否是適合你的數據庫取決於很多因素：

http://en.wikipedia.org/wiki/Entity-attribute-value_model

http://karwin.blogspot.com/2009/05/eav-fail.html

http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back

列過多是不真的是其中之一。

來源

2010-12-16 19:38:37

如果表格中的更改和添加並不是一件壞事，它意味着它們能準確反映業務需求的變化。

來源

2010-12-17 00:54:52 sqlvogel

如果變化和附加是連續的，那麼也許你需要坐下來做更好的定義需求。現在我不能說30列是否會出現問題，因爲它取決於它們的寬度以及是否應該將其移到相關表格中。一旦如果你有像phone1，phone2，phone 3這樣的字段，你就有一團亂麻，需要將其分解到user_phone的相關表中。或者，如果所有列都很寬（並且您的整個表格寬度比數據庫存儲數據的頁面寬），而且有些不是查詢常用的那些列，那麼在相關的表中可能會更好一些，一個關係。我可能不會這樣做，除非你有實際的性能問題。

然而，所有可能的選擇，您所描述的EAV模型是從maintainabilty和性能的角度來看，最糟糕的一個或兩個。對這個模型寫出體面的查詢是非常困難的。

來源

2010-12-17 22:36:17 HLGEM

有多少個數據庫表列太多？

回答

相關問題