動態創建表以存儲用戶內容是否是個好主意？

Question

我目前正在設計一個應用程序，用戶可以在其中創建/加入組，然後在組內發佈內容。我試圖找出如何最好地將這些內容存儲在RDBMS中。

選項1：爲所有用戶內容創建一個表。此表中的其中一列將是groupID，指定發佈內容的組。使用groupID創建索引，以便快速搜索特定組內的內容。所有的內容讀取/寫入都會打到這張單獨的表格。

選項2：每當用戶創建一個新組時，我們都會動態創建一個新表。類似於group_content_ {groupName}。所有內容讀取/寫入將被路由到特定組的動態創建表。

優點爲選項1：

1. 它更容易搜索多個論壇的內容，用一個單一的簡單的查詢，對單個表進行操作。
2. 由於內容表是靜態的且定義明確，因此構建簡單的交叉表查詢會更容易。
3. 由於只有一個表來維護，因此更容易實現模式更改和對索引/觸發器等的更改。

贊成選項2：

1. 所有的讀取和寫入操作將在衆多的表來分配，從而避免可能導致大量的流量創下了單個表中的瓶頸（但無可否認，這些表仍然在一個單一的數據庫中）
2. 每個表的大小都會小得多，允許更快的查找，更快的模式更改，更快的索引等。
3. 如果我們想在未來分割數據庫，如果所有的數據已經被「分解」，那麼就會更容易nt表。

從性能/開發/維護的角度來看，上述2個選項之間的一般建議是什麼？

Answer 1

這是一個不容易的事情。 （1）是要走的路。

您將這些列爲第二種方法的優化。所有這些都是誤解。請參閱下面的評論：

所有讀取和寫入將在衆多表分發，從而 避免可能導致大量的流量打 一個表中的瓶頸（但無可否認，所有這些表仍處於 single DB）

讀寫操作可以很容易地分佈在一個表中。唯一的問題是在頁面內寫入衝突。這可能是一個非常小的考慮因素，除非您每秒處理超過數十個事務。

由於下一個項目（部分填充的頁面），您實際上更適合使用大多數填充的單個表格和頁面。

每個表的大小會小得多，允許更快的查找， 更快的架構變化，更快的索引，等等

小表可以是一個性能災難。表格存儲在數據頁面上。每個表格都是部分填充的頁面。你最終得到的是：

• 大量的磁盤空間浪費。
• 頁面緩存中浪費了大量空間 - 可用於存儲記錄的空間。
• 在部分填充的頁面中浪費了大量的I/O讀數。

如果我們要分片的DB在未來，如果所有的數據已經在不同的表「碎片化」的過渡會更容易 。

Postgres支持表分區，所以你可以在不同的地方存儲表的不同部分。這應該足以滿足傳播I/O負載的目的。

Answer 2

計算中的一個主要罪過是優化太早。這是20年以上的DBA的觀點，你高估了這些組將發生的IO。RDBMS非常擅長在一組標準表中查詢和編寫這種類型的信息。最壞的情況下，你可以稍後分割它們。您將擁有更多的搜索功能和管理簡易性，而不是每個用戶設置一組表。

想象一下，如果模式需要改變？你真的想要更新數百或數千個表，或寫一些長腳本來解決一個普通的問題嗎？堅持使用一組表並忽略分片。相反，想一想「如果有必要，我們可能會在某一天劃分桌子」

Answer 3

選項1：性能=正常發展=易維護=易

選項2：性能=快速發展=複雜的維護=硬

我建議選擇Oprion1和大桌子，您可以管理具有更好的指數或現金指標（對於某些數據庫）的性能和最後一件事情沒有什麼幫助使第二個選項2，因爲開發維護時間是致命的因素