如何處理具有可變列的表格設計
我有一個表設計方案，並且作為非 DBA 類型，想知道哪個更具可擴展性。
假設您被要求記錄一個都市區的房屋資訊，從一個小社區（200 所房屋）開始，但最終增長到 5000000 多所房屋。
您需要儲存基本資訊：ID#（我們可以用作唯一索引的唯一批次#）、Addr、City、State、Zip。好的，簡單的表將處理它。
但是每年，您都會被要求記錄有關所有房屋的額外資訊 - 以及每年會更改哪些資訊。因此，例如，第一年，您被要求記錄所有者的姓氏和平方英尺。第二年，您被要求保留姓氏，但丟棄平方英尺並開始收集所有者的名字。
最後 - 每年額外的列數都會改變。可能會從 2 個額外的列開始，然後明年增加到 6 個，然後再降到 2 個。
因此，一種表格方法是嘗試將自定義資訊添加為房屋表格中的列，因此只有一張表格。
但是我有一種情況，有人為此列出了表格：
“House Table”列：ID、Addr、City、State、Zip - 每間房子一行
ID Addr City State Zip ------------------------------------------- 1 10 Maple Street Boston MA 11203 2 144 South Street Chelmsford MA 11304 3 1 Main Avenue Lowell MA 11280“自定義資訊表”列：ID、名稱、值 - 表看起來像：
ID Name Value 1 Last Name Smith 2 Last Name Harrison 3 Last Name Markey 1 Square Footage 1200 2 Square Footage 1930 3 Square Footage因此，每個單獨的房屋記錄都有多行。每年所需的可選資訊發生變化時，此表都會重新建構，因此明年它可能如下所示：
1 Last Name Smith 2 Last Name Harrison 3 Last Name Markey 1 First Name John 2 First Name Harry 3 First Name Jim最終你積累了 100,000 行房屋，一年有 10 條額外的資訊；第二個表現在有 1,000,000 行資訊，其中許多具有冗餘（描述）資訊。總體而言，數據庫要求是人們每天需要數千次獲取房屋行資訊 + 相關的自定義欄位值。
所以我的問題是：改為：
A）佈局房屋表，猜測最大自定義列數（可能稱為“1”到“10”）並將這些自定義值插入房屋行
要麼
B）將自定義資訊儲存在房屋表中，但是每年當需求發生變化時，僅使用自定義資訊所需的列數重建房屋表，其想法是要求可能會發瘋，而您永遠不知道最多有多少可能會要求可選欄位？
謝謝，希望這是有道理的！
你幾乎有4個選擇：
NoSQL -定義每條記錄都儲存為一組鍵/值對。它非常靈活和快速。並非所有的報告編寫者都支持這種儲存方式。NoSQL 有許多範例數據庫實現。現在似乎最流行的一個是 MongoDB。
EAV -定義這是您將整個表或部分（在另一個表中）翻轉的位置。如果您內部已經有一個無法輕易擺脫的關係數據庫，那麼這是一個不錯的選擇。您提供的自定義資訊表範例是 EAV 表的一個很好的範例。
帶有 XML 列的標準表- 可以將其視為 NoSQL 遇到關係表。儲存在 XML 列中的數據可以是 XML 支持的任何格式，包括多個相關的子數據。對於您知道將成為“正常”列的列，可以將它們建構為適當類型的列來儲存數據（姓氏、地址、城市、州等）。
具有大量額外列的標準表- 您有一個關係數據庫，您不能使用 XML 或 EAV，並且 NoSQL 不是一個選項。添加大量每種類型的額外列。我猜 30 個或更多 varchar、30 個或更多整數、15 個或更多數字。並且一旦您使用一列作為值，就不要重複使用它。也不要刪除該列。
在所有這些解決方案中，我個人的看法是，您會發現 NoSQL 或 EAV 方法是最成功的，並且重構程式碼和架構的量最少。
您將遇到這樣一種情況，即您在一年而不是下一年收集數據，然後再收集數據。試圖用正確的資訊更新舊數據是有問題且昂貴的。儲存既不是。
要回答你關於這兩個選項的問題，我覺得都不對。A) 會把你鎖在裡面，B) 工作量很大。您描述的目前架構還不錯（除了將資訊名稱（“名字”、“平方英尺”等）作為字元串而不是引用到查找表的 ID 之外。
但是，在我看來，這似乎是 NoSQL 數據庫 ( http://en.wikipedia.org/wiki/NoSQL ) 的一個很好的候選者。雖然我從未使用過這樣的數據庫，但您所描述的是一個可以解決的典型場景。