我正在使用一個應用程序，我們將客戶端數據存儲在每個客戶端的單獨SQL數據庫中。到目前爲止，這一切都非常成功，甚至有一些錯誤的代碼從數據庫中選擇了錯誤的客戶ID，並且由於數據庫中的唯一數據屬於該客戶端，所以損失並沒有發生。我的擔心是關於您在SQL Server上實際擁有的數據庫數量。SQL Server上有多少數據庫？
您創建的每個新數據庫是否有額外開銷？我們最終遇到了一堵牆，我們只需要在一臺服務器上安裝多個數據庫？ SQL Server規範說，你可以擁有類似32000數據庫的東西，但這是可能的，是否有人在一臺服務器上有大量數據庫，以及遇到了什麼問題。
感謝，
弗蘭克
的上限是
實例：爲32K數據庫
有效限制取決於負載，用途，數據庫大小等
編輯：和帶寬悅巴內特提到..我忘記了網絡的瓶頸大家忘掉......
的ISP通常有一個由數百或數千個數據庫共享一個數據庫服務器。
所有多個數據庫的最大問題是在進行模式更改時保持它們全部同步。至於實際數量的數據庫，你可以擁有系統，並且像往常一樣依賴它。這取決於服務器的強大程度以及數據庫的大小。很可能您希望在某個時間點擁有多個服務器，這不僅僅是因爲它對您的客戶來說會更快，而且因爲如果服務器發生某種情況，它會一次減少處於風險中的客戶端數量。在什麼時候，只有你的公司才能決定。當然，如果你開始大量超時，可能會指出另一臺服務器（或者修復你可憐的查詢也可能會這樣做）。大客戶往往會付出額外費用在一個單獨的服務器上，所以在您的定價中考慮。我們有一個客戶對自己的數據非常偏執，我們不得不擁有一臺甚至與其他服務器不在同一地點的單獨服務器。他們付出了巨大的代價，因爲我們不得不租用額外的空間。
你真正要問的是可擴展性;雖然理想情況下在一臺服務器上設置32,000個數據庫可能不是有利的，但有可能（儘管不推薦）。
讀 - http://www.sql-server-performance.com/articles/clustering/massive_scalability_p1.aspx
我會將鏈接放在底部作爲參考，並且不會保存。我對這種混亂表示歉意。 – 2010-07-19 15:25:16
架構上來說，這是一般正確的判罰。您已經看到了第一個巨大的優勢 - 通常，損失可能僅限於單個客戶端，並且您幾乎沒有客戶端訪問另一個客戶端數據的風險。但是您錯過了另一個巨大的優勢 - 您不必將所有客戶端保留在同一臺數據庫服務器上。當你的服務器變得足夠大以至於服務器受到影響時，你可以用最少的努力完全卸載客戶端到另一個服務器上。
我還打賭你會在服務器用盡數據庫之前耗盡帶寬來管理數據庫。 。 。
我知道這是一箇舊的線程，但它與我們在過去2年使用的相同結構以及當前在3臺服務器上運行1768個數據庫的結構相同。
我們有如下設置（不包括後視鏡等）：
上面提到的最大的問題是保持數據庫結構的同步！爲此，我最終編寫了一個小型.NET窗體，查找master數據庫中的所有客戶，並粘貼代碼執行，並通過獲取數據庫位置和執行過去的SQL來循環。
創建新客戶也給我們帶來了一些問題，所以我最終爲我們的銷售人員編制了一個管理系統，它創建了一個基於非活動「空白」數據庫備份的新數據庫，因此我們擁有最新的數據庫而無需重新編寫整個數據庫創建腳本的腳本。然後，將主要數據庫中的客戶詳細信息與創建數據庫的位置一起插入，並從舊版本的軟件遷移任何舊數據。所有這些都是在移動之前在單獨的實例上完成的，因此減少了任何SQL鎖定。
我們現在正在爲我們的下一個版本的軟件遷移到一個數據庫，因爲數據庫冗餘幾乎不可能有這麼多的數據庫！這是一個巨大的考慮因素，因爲SQL會創建一些等待任務，這些任務會鏡像每個數據庫的數據，一旦您開始將數據庫放大並失去控制，並且系統幾乎完全負責同步並且可能由於剪切而鎖定線程數。請參見下面的Microsoft文檔30頁：
SQLCAT's Guide to High Availability Disaster Recovery.pdf
然而，我有關於搬遷到一個單一的數據庫，由於一些擔憂懷疑上面提到的，如在目前的客戶有每一個程序不斷檢查只能訪問他們的數據，而且一些小問題中的事情現在也會影響到每個數據庫，比如表索引等等。同時，我們的客戶還有3臺服務器，但單個數據庫意味着我們有冗餘，但如果錯誤在數據庫內而不是服務器下降，那麼每個客戶都會下降，而不僅僅是1個客戶數據庫。
總之，這取決於你在做什麼，如果你想要冗餘;對我而言，冗餘現在是關鍵，而且完美世界中的其他任何事情都不應該發生（比如導致數據庫中所有人都出錯的錯誤）。我們只是開始期待從一箇舊的自我託管軟件轉移到系統，並迅速變成200,500,1000,1500 ......我們現在每年有超過75萬用戶使用我們的系統，並且在8月/ 9月我們在線用戶超過15,000（預計今年達到20,000）。
希望這是幫助沿線有人:-)
問候
利亞姆
哇，這是很多數據庫！我最終也在我正在研究的項目中實現了這個結構，並且遇到了同樣的陷阱。這種類型的設置需要更多架構和定製工具，然後是單個數據庫系統，所以任何其他人都應該注意，它不會因爲內心的缺失而受到警告。 – Frank 2014-07-04 16:30:31
完全同意「不適合膽小的人」一點，因爲我們必須自定義這麼多才能讓生活更輕鬆。我已經定製了備份例程來備份每個備份並將其上傳到Amazon S3存儲。 就像我說的，現在對我來說主要的突破點是我們不能提供這種模式的冗餘，沒有大量的人工輸入來移動數據庫。 – 2014-07-07 10:54:06
我在考慮，我們目前正在開發一個託管的應用程序類似的設置，所以任何真實世界的戰爭故事將是最受歡迎的:) – elo80ka 2010-07-19 14:48:15
到目前爲止，這個想法已經非常成功，但它需要大量的工具代碼來支持。例如，我們有一個用於創建新網站的管理員應用程序以及一個將客戶端從一臺服務器移動到另一臺服務器的導入/移動主要是爲了調試，但是在將來我們計劃使用兩個prod服務器來平衡負載。 – Frank 2010-07-19 17:31:28
單獨數據庫對於每個客戶端的另一個巨大副作用是它迫使您設計一個可重置環境，您可以在其中快速創建新的應用程序實例並對其執行單元/手動測試。 – Frank 2010-07-19 20:19:19