爲未知數量的列設計數據表的最佳方法是什麼？

Question

我試圖建立一個數據表結構，最好支持以下標準：

1）我不知道表有多少列。

• 我在某些情況下可能需要6列，或在其他情況下需要10列。我不認爲這張桌子需要20列或更多列，但我也不能保證永遠不會需要。

2）我需要考慮存儲空間和報告速度。

• 此表需要存儲數百萬條記錄，並且報表將針對此表運行。我知道擺脫高度規範化的表格從報告的角度來看很困難，所以我想解除報告的規範化。但是，我也不知道是否爲了避免一些規範化而簡單地違約到大量的列是一個好主意，因爲我可能會在表的末尾的許多列中結束大量的NULLS，那些將（我認爲）都佔用了一些存儲空間。

3）如果我必須在存儲空間和報表性能之間進行選擇，我會在性能方面表現出色。我不是一個商業智能專家，我不是一個T-SQL專家（我將使用SQL Server），所以我很確定在這裏有很好的一點，我只是忽略了它。因此，我再次轉向了精彩的SO社區尋求建議，並且讓我的頭骨有一些感覺。

在這種情況下你會如何設計表格？我錯過了什麼細節，仍然需要考慮？

Answer 1

大多數通用表設計的列值根據用戶設置決定/如此將導致性能較差，因爲所有查詢都是動態的。

合理的做法是提出對列數的估計，並讓未使用的列最初爲空。

你能舉個例子說明你的故事是什麼嗎？引發這個問題的一個例子是當你有一個產品表時，有些產品只有5個屬性，有些產品有50個。正如我上面所說的，你最好用50列創建表（如果你想有一個產品表），並在需要時將其他列作爲null。

報告工具和大多數RDBMS在聚合和分組過程中處理空值。

Answer 2

表中的列表示要存儲的實體的規格。說你不知道有多少列將被存儲意味着你不知道要存儲的東西的規格。換句話說，你想建立一個系統而不知道它會存儲什麼。關係數據庫基本上沒有設計成處理這個並且性能良好且可維護。爲了表現良好且可維護，關係數據庫依賴花費時間來確定要存儲的實體的屬性及其屬性，然後構建適當的模式。

因此，使用關係數據庫的最佳性能和最可維護的解決方案是根據需要構建模式，這意味着需要收集有關要存儲的規格。

也就是說，關係數據庫有其他選擇，比如所謂的「nosql」數據庫，它可能比關係數據庫更適合超級彈性設計的需要。這些示例包括MongoDB和CouchDB。