針對大量用戶的數據庫設計

Question

哪一個更好a或b： a）。每個用戶7張桌子，例如user7消息，user7mail等。在這種情況下，如果我們有1000個用戶，則會有7000個表。 b）。 7個表，例如消息，郵件等，每個usr的所有messasges或郵件將在同一張桌子上。 在這種情況下，對於1000個用戶，我們只有7個表。

Answer 1

在大多數情況下，在現代硬件和合理的調整，你的數據庫應該是隻要你的數據真的是關係型的，就能支持數千萬條記錄而不會有太多的痛苦。如果您正在搜索文本，存儲分層數據，存儲文檔或運行報告，則還有其他選項（例如NoSQL）。

儘可能地堅持使用關係數據庫的正統方法;這意味着normalization,query tuning，使用緩存和拋硬件的問題。

只有當你已經證明了你有一個性能問題是值得看的更奇特的解決方案。在RDBMS世界中，這可能意味着數據（類似於「每個用戶的表」想法）。或者，您可以跳轉到NoSQL。

您的「每用戶表」策略的問題在於，在通過索引查詢時（在現代RDBMS上搜索帶有1行或帶有百萬行的表時搜索索引幾乎不會產生任何好處用於查找數據的差異）。對於不打索引操作，您應該看到一個像樣的增益 - 但是這通常是你沒有真正在第一地點關係的標誌......

它使得開發客戶端應用程序，而容易出錯，並且比它需要更復雜，特別是在創建適度複雜的SQL查詢（例如多表連接）時 - 因此調整這些查詢將變得更加困難。您將無法使用可用於管理數據庫查詢的工具（例如ORM工具），因爲它們都基於「標準」關係模型。

的最大問題是改變數據庫 - 如果你要新增屬性的「消息」，你不得不重複這種變化在7000個表。你要麼花費大量時間編寫自定義的數據庫管理腳本，要麼讓人類重複同樣的事情幾千次（並且做出難以察覺的錯誤）。

Answer 2

情況B會好很多，只要確保你的用戶有自動遞增USER_ID類型字段，並且表在一起，通過這個ID例如鏈接

user_id email 
1000  hello 

這將提高查找速度，因爲你不必iclude功能選擇從搜索表中1000年的數據的特定部分（在這種情況下，它會搜索表中的列，直到它找到了正確的這將是可笑的）

但如果你正在尋找一個特定的表（例如，你只需要消息）只有1個表將被包括在查詢中，更快，更容易管理所有的表在管理員級別。

而且，甚至更好的想法是1代表數列，說「通信」表，也能像

user_id email messages 
1000  hello hi