根據某個類別ID，將一個大的SQL表分成幾個表，你有什麼想法？

Question

我們有一張大桌子，可以在很多網站上爲許多不同的存儲過程提供服務，但通常只處理表格中與使用該網站相關的數據。

換句話說，那將是錯誤的websiteID拆分表？

Answer 1

如果這意味着你在多臺服務器上安裝多個數據庫，那麼這就是推薦的方式來擴展之一。如果你指的是同一臺服務器上的多個表（不管是否是同一個數據庫），你的收益將會很小，如果有的話;而且您的管理開銷可能會增加以保持同步。如果在任何碰到多個表的查詢中有任何情況，這些效率會降低。

效果不太可能是好的或生病的。你期望什麼是好處？ （這是反模式的典型RDBMS過早優化，順便說一句。）

Answer 2

你的意思是你想擁有的一個BigTableForAllWebsites代替BigTableForWebsite1，BigTableForWebsite2，BigTableForWebsite3等？這讓我覺得我的數據庫中，純粹的胃有點不適......

我不認爲這會給你的性能提升，因爲每個接入仍然會工作對單個數據庫（可能存儲在單個一組文件）。

Answer 3

是的，這是錯的。你應該保持在一個表和索引在websiteid。如果你真的想讓它們看起來分開，你可能想使用分區視圖，但我認爲這不是必須的。

在SQL方面你永遠不應該分手基於其過度的長度（即行數）的表，但你可能會考慮分手錶基於過度的寬度（即列數）。

Answer 4

如果您希望將應用程序轉移到隔離自己的表，你會過得更好設置每個實例的數據庫，而不是試圖做到這一點的應用程序。這具有以下優點：

• 查詢的SQL不會 更改。

• 更容易通過 數據庫比表分區，以確保數據的安全。 您可以爲客戶提供更多 靈活的數據訪問權限，而不會影響其他客戶的數據。

• 如果需要，您可以在每個客戶的基礎上實施獨立的 備份/恢復制度。

• 如果需要 ，通過將 某些客戶移動到另一個服務器上，可以更容易「擴展」。

• 的應用程序體系結構 簡單，因爲它不必是 明確意識到每個查詢客戶 過濾。

在每個用戶爲基礎建立多個表意味着你必須保持一個單獨構建的應用程序或生成所有涉及這些表的SQL語句。這是混亂和難以擴展到大量的客戶。

作爲一個概括，如果你有一個相對簡單的應用程序和大量的客戶，帶過濾器的單個表可能是更合適的解決方案。對於客戶較少的更復雜的應用程序，最好的方法是設置多個數據庫併爲每個客戶提供一個應用程序實例。