在上傳新內容時動態生成SQL表-一個壞主意？

Question

我有一個有趣的問題，我一直在研究，並希望得到一些建議：

我試圖創建一個模仿需求管理工具的基本功能的工具，作為公司項目的一部分。

基本設計是類似於Windows資源管理器的文件夾和文檔設置。 可以在GUI中打開文檔，進行編輯和保存。

該文檔本身包含一個分層的電子表格（如果有意義的話，請考慮使用帶有章節的Excel）。 每章都包含行，這些行實際上只是一些需求文本+一些補充它的值。 當顯示時，需求文本和屬性值顯示為具有過濾功能的獨立列（非常類似於Excel）。

代表這類程序的用戶/權限/文件夾層次結構/等非常簡單，但是我掛在這里的是文檔內容本身...

我最關心的是大小及其與性能的關系：作為此工具的一部分，我不僅打算存儲每個文檔的當前狀態，而且要存儲自第一天以來所做的更改的整個列表（與SVN相似） ，然后提供對更改歷史記錄的快速訪問。

平均而言，我預計該回購中會包含約500個文檔； 每個文檔可能會有約20,000個活動行； 在一年的時間里，假設進行約20,000次編輯並非沒有道理（意味着每個文檔本身每年將額外獲得20,000行）。

乘以文檔數，得出的行數接近10,000,000（第二年和第二年又增加了10,000,000，依此類推）。 可以清除舊的歷史記錄，但是只能由管理員執行（最好不要執行此操作）。

如我所見，我有兩種方法可以處理這種情況：

• 我可以嘗試代表一個表中所有文檔的所有行的列表（很像phpBB如何將所有論壇的所有帖子存儲在一個表中），或者...

• 我可以嘗試將每個文檔的行存儲在唯一命名的表中（這意味着每個文檔都有自己的表）； 該表必須被賦予唯一的名稱，而主表將包含所有文檔的列表以及與每個文檔相對應的表名。

所以我的問題是：哪個更可取？ 都不是很好的選擇嗎？ 鑒於需求，任何人都可以針對您認為更合適的方法提供建議嗎？

Answer 1

如果您在應用程序的正常日常運行中以編程方式創建和/或銷毀表，那么我會說這是一個非常不好的信號，表明數據庫設計中有錯誤。

數據庫系統可以並且確實處理具有這么多行的表。 要在該行數上進行任何有意義的查詢，您確實必須謹慎而省事地選擇索引。 我的意思是，您確實必須完全了解如何查詢表格。

但是，我敢說，與您提議的僅基於ID或數字任意創建新表的方法相比，實現起來要簡單得多。 而且，復雜度越低，維護起來就越容易，並且引入難以調試的討厭的bug的機會也就更少。

如果您真的很想拆分為多個表，那么建議您研究一下其他人如何進行數據分區 。 與其動態創建表，不如從一開始就根據您認為可能需要的數量創建固定數量的表，然后根據記錄中表中有多少記錄之類的任意內容將記錄分配給這些表。時間，但可以預見-在示例中給出了用戶的郵政編碼，或者是該文檔所在的類別，或者是創建該文檔的用戶的域名或國家/地區，或者可以用來輕松確定記錄位置的邏輯最終會合理分散。

以這種方式進行數據分區（創建所有分區）的好處之一是，如果將來需要的話，遷移到多個數據庫服務器相對容易。 如果要動態創建和銷毀表，那將使其難以實現。

Answer 2

多表方法要考慮的幾點：

• 在所有文檔中查找信息是否必要？ 如果是的話，您將需要在所有表格中進行搜索，但這並不是那么簡單。
• 如果架構發生更改，那么更新數據庫並不容易，因為代表同一類型實體的所有表都需要更改
• 跟蹤有關用戶編輯的信息也不是那么簡單，因為它將信息分為多個編輯（例如，考慮“用戶修改了哪些文檔”的情況）

您是否考慮過替代方法來存儲數據？ 有必要將數據庫中的每個excel行存儲為表行嗎？ 將數據存儲為xml，僅將idexes保存在數據庫中？ 還是只存儲跟蹤修改和文檔版本？ 應用程序可以承擔一部分數據庫負擔並進行過濾嗎？

Answer 3

您可能需要考慮某種文檔管理系統。 這聽起來像SharePoint可以做的事情-可以將其設置為在簽入文檔時創建文檔的新版本。文檔也可能已分配了元數據，這可能是必需的。

Answer 4

有很多表沒有錯。 看起來有很多表對您來說是一種更合理的方法。