大量用戶的數據庫設計

Question

a或b哪個更好：a）。 每個用戶7個表，例如user7消息，user7mail等。在這種情況下，如果我們有1000個用戶，則將有7000個表。

B）。 7個表，例如消息，郵件等。每個usr的所有消息或郵件都將在同一表上。 在這種情況下，對於1000個用戶，我們只有7個表。

Answer 1

情況B會好得多，只需確保您的用戶具有一個user_id類型字段，該字段會自動遞增，並通過該ID將您的表鏈接在一起，例如

user_id email
1000     hello

這將提高查找速度，因為您不必包含從1000個表的搜索中選擇特定數據的功能（在這種情況下，它將搜索表的列，直到找到具有正確列的正確表為止，太可笑了）

但是，如果您要搜索特定的表（例如，您僅需要消息），則查找中將僅包含1個表，這樣可以更快，更輕松地在管理員級別管理所有表。

但是，甚至更好的主意是1個表包含幾列，例如“通訊”表

user_id  email   messages
1000     hello   hi

Answer 2

在大多數情況下，在現代硬件上並通過合理的調整，只要您的數據確實是關系型的，您的數據庫就應該能夠支持數千萬條記錄而不會帶來太多麻煩。 如果要搜索文本，存儲分層數據，存儲文檔或運行報告，則可以使用其他選項（例如NoSQL）。

盡可能使用正統的關系數據庫使用方式； 這意味着規范化，查詢調整，使用緩存以及將硬件投入問題。

僅當您證明自己存在性能問題時，才有必要尋找更多奇特的解決方案。 在RDBMS世界中，這可能意味着對數據進行分區（有點類似於“每個用戶的表”的想法）。 或者，您可以跳到NoSQL。

您的“每用戶表”策略的問題在於，按索引查詢幾乎沒有任何好處（在現代RDBMS上，在命中索引時搜索包含1行的表或包含百萬行的表對查找索引幾乎沒有區別。數據）。 對於未達到指標的動作，您應該會看到不錯的收益-但這通常表明您一開始並不是真正的人際關系……

這使得開發客戶端應用程序非常容易出錯，並且比需要的過程更加復雜，尤其是在創建中等復雜的SQL查詢（例如，多表聯接）時，調整這些查詢將變得更加困難。 您將無法使用可用於管理數據庫查詢的工具（例如ORM工具），因為這些工具都是基於“標准”關系模型的。

最大的問題是更改數據庫-如果必須在“消息”中添加屬性，則必須在7000個表中重復該更改。 您將花費大量時間來編寫自定義數據庫管理腳本，或者使一個人重復同一件事數千次（並導致難以發現的錯誤）。