樣式問題 - 有很多字段的數據庫表

我開始一個新的項目，我必須解析一個文檔並將其存儲在數據庫中。本文檔包含簡單鍵值對的幾個部分 - 約10個部分，總共約100對。我可以爲每個部分創建一個表，並且它們全部映射到一個聚合。或者我可以有一個約100個字段的桌子。我被卡住了，因爲我不想製作一張很大的表格，但我也不想製作這麼多的一對一映射。那麼，我要製作一張大桌子，還是製作一堆小桌子？實際上，據我所知，實際上並沒有什麼區別。如果有，請通知我。樣式問題 - 有很多字段的數據庫表

編輯一個例子是所希望的，所以我會提供一些可能的幫助。

Document 
    - Section Title 1 
    - k1: val1 
    - k2: val2 
    ... 
    - Section Title 2 
    - k10: val10 
    ... 
    ... 
    - Section Title n 
    - kn-1: valn-1 
    - kn: valn

而且我必須使用關係數據庫，所以不要打擾否則。

來源

2011-01-10 geowa4

你能舉個例子嗎？這兩種情況都聽起來並不理想，這可能是因爲我沒有想到要做的事情。 – 2011-01-10 22:28:03

如果你有很多，這個大文件的許多實例存儲（現在的和/或一段時間內），如果這個文件的每個實例將對那些100個值+列，如果你想要在RDBMS中存儲所有數據actross行和列所固有的強大功能和靈活性，那麼我會把它全部存儲爲一個大（儘管很醜）的表。

如果給定部分中的所有「項目」總是被填充，但是可能填充或者不填充所有部分，那麼每個部分有一個表格可能是有價值的......但聽起來不像這樣是這樣的。

請注意以上「ifs」。如果它們中的任何一個太搖擺不定，那麼大桌面的想法可能會比它的價值更加痛苦，而其他想法（比如@ 9000的NoSQL想法）可能會更好。

來源

2011-01-10 22:44:15

我希望我可以使用NoSQL。它更適合。但客戶端不能支持，所以我卡住了。那張巨大的桌子是所有形式都有的共同點，整個表格必須填寫完整。我還有其他專門針對各部門的表格。 – geowa4 2011-01-13 16:50:15

Table document(
    PK - a surrogate key 
    name - the "natural" key 
) 

Table content(
    PK - the PK of the parent document 
    section title 
    name 
    value 
)

是的，每個文檔有100行的名稱/值對。但是，您可以輕鬆添加名稱和值，而無需修改數據庫。

來源

2011-01-10 22:25:30

通過這種方法，NoSQL數據庫可能具有優勢。 – 9000 2011-01-10 22:32:22

如果數據僅用於只讀目的，並且您的xml沒有要求您更改數據庫方案（更改），那麼我不會看到任何問題解除規範化爲單個表。另一種方法可能是看EAV models

來源

2011-01-10 22:31:14

樣式問題 - 有很多字段的數據庫表

回答

相關問題