我正在處理半打數據庫。數據庫都具有相同的模式，相同的SP等。對於最初設計數據庫的人來說，使用多個數據庫的動機的很大一部分是效率;另一種方法是在數據庫中的幾乎每一個表和sp上添加一列，以指示正在處理哪組數據，從而導致一個巨型（因此較慢）的數據庫而不是幾個小型數據庫。代替具有指示要查詢哪組數據的列，連接字符串用於選擇正在被命中的數據庫。如果我想將許多DB合併到一個數據庫中，我應該記住什麼？
我真的不喜歡這個組織的唯一原因是它涉及很多代碼重複，從而傷害了維護。例如，每次我希望更改存儲過程時，都需要在每個數據庫上運行alter語句。
我考慮過的一個解決方案是將所有數據組合成一個大型數據庫，在整個地方添加一個額外的列以指示數據將在哪個數據庫中，如果我沒有合併它。然後，我可以通過此列的值對所有表格進行分區。理論上，所有這些數據的結果都是道德上與現在相同，但是沒有索引，模式，SP等中的冗餘。
我的問題是這樣的：
大家都會在某個時候處理這個問題。我個人的觀點是，多個數據庫是背後的痛苦，並不是更快。由於維修令人頭疼，他們很痛苦。如果索引設置正確，根據需要在每個表中添加額外的列都不會減慢您的過程。而且你的維護將會容易得多。此外，跨多個數據庫進行交易可能會很麻煩並涉及MTC。
順便說一句，使用單個數據庫通常稱爲多租戶數據庫。你可能想研究一下。但是如果可能的話，我會避免使用多個數據庫。
我和蘭迪不一樣。
多租戶模式有其優勢。
其中之一，無論您有5個數據庫還是500個，維護沒有太大的不同。在某些時候，您不再考慮維護各個數據庫並查看集合。是的，您必須序列化備份，並且您無法一次對所有數據庫執行索引重組/重建。
但是，對於跨越多個或多或少相同的數據庫的代碼更改，有很多簡單的方法可以將很多事情腳本編寫到多個數據庫，而無需額外增加額外的手指。我使用了一種名爲SQLFarms Combine（現在由JNetDirect出售）的工具，但還有其他產品，例如RedGate MultiScript，我沒有玩過。
我最喜歡的多租戶模式是，當你增長和規模化，突然需要一個新的數據庫服務器時，很容易將其中一個租戶（比如說最繁忙或增長最快的）轉移到新的服務器。如果每個人都被卡在同一個數據庫中，那麼僅提取他們的數據就變得非常困難，特別是如果要最小化停機時間的話。在多租戶模式中，您可以爲其數據庫設置鏡像，然後在準備就緒時切換主服務器。
由於我使用這個數據庫的方式，宕機並不是什麼大事。 – Brian 2010-02-12 21:49:48
我會支持組合這些數據庫。 SQL Server中還內置了其他一些工具來解決非常大的數據庫潛在的性能下降問題，例如第二個物理磁盤上的附加索引，分區，集羣等。將模式更新部署到許多不同的數據庫所涉及的頭痛和開銷在單個數據庫中輕鬆處理時可能非常耗時。我認爲在這種情況下，SQL Server可以很好地擴展 - 讓數據庫服務器完成它設計的任務並提供對數據的響應式訪問。您可以專注於應用程序設計，並將存儲模型留給SQL Server。另外，雖然上面沒有提到這一點，但我懷疑在使用這個「多數據庫」模型的應用程序中涉及到一定程度的動態SQL，因爲您必須根據您的某些內容在數據庫之間切換知道，所以它不能被硬編碼到應用程序或配置文件中，這意味着連接字符串或實際的SQL語句必須隨時生成，這可能是一個非常大的安全風險（請閱讀「SQL注入「如果你不熟悉動態SQL的潛在風險）。
將模式更新部署到10個數據庫與將它們部署到1實際上沒有什麼不同。您只需使用正確的工具即可。 至於動態SQL，不，如果你設計的話不對。我有一個500+分的多租戶模型，唯一的動態SQL要麼獨立於數據庫（因爲它與租戶無關），要麼涉及中央數據庫收集性能指標等。應用程序有一個配置文件連接到控制數據庫，控制數據庫告訴它連接字符串用於完成其真正的客戶工作。 – 2010-02-12 20:05:23
我關於動態SQL的觀點是，這不是來自應用程序或基於用戶輸入的動態SQL，而是從SQL Server中的維護作業調用的，並且比大多數人更典型的動態SQL類型被恐懼嚇倒。 – 2010-02-12 20:10:00
根本沒有涉及動態sql。數據庫在關係方面幾乎完全相互獨立，因此不存在跨數據庫連接。正如我前面提到的，切換完全是通過更改連接字符串來完成的（即更改初始目錄） – Brian 2010-02-12 21:46:53
術語「多租戶」是我爲了研究這個問題而需要的。 – Brian 2010-02-12 22:00:19