2012-08-15 44 views
1

我被要求開發一個應用程序,該應用程序將用於多個業務單位。每個單元的應用程序將基本相同,但程序上的差異較小,這不會改變底層數據庫的結構。我應該爲每個業務單位使用一個數據庫,還是爲所有單位使用一個大數據庫?業務單元完全獨立一個大的數據庫,還是每個客戶端?

回答

2

我的偏好是每個客戶端一個數據庫。優點:

  • 如果客戶端變得太大,他們很容易移動 - 備份,恢復,更改連接字符串,繁榮。當他們的數據與大量數據庫中的其他數據混合在一起時,試着這樣做。即使你使用模式和文件組來隔離,移動它們也不是一個蛋糕行程。

  • 同上刪除客戶端的數據。

  • 顧名思義,你需要將每個客戶的數據分開。這往往會成爲一種需求,有時也是一種需求。有時它甚至會有法律約束力。

  • 數據庫中的所有代碼都更簡單 - 它不必包含客戶端的模式(不能被參數化),並且您的表不必包含指示客戶端的額外列。

很多人會聲稱管理200或500個數據庫比管理10個數據庫困難得多。根據我的經驗,這並沒有什麼不同。您可以構建自動化腳本的腳本,錯開索引維護和備份作業等。

潛在的缺點是,當您進入每個實例的4位數或更高數據庫的領域時,您想要開始考慮在哪裏多個服務器(門檻實際上取決於工作負載和硬件,所以我只是選擇一個數字)。如果您正確地構建系統,添加第二臺服務器並在其中放置新數據庫應該非常簡單。同樣,應用程序應該知道每個客戶端的連接字符串,並且您通過使用不同的服務器正在執行的操作是更改連接字符串指向的實例。

關於dba.SE的一些問題你應該看看。他們是不是所有的SQL服務器,但許多概念和挑戰是普遍的:

https://dba.stackexchange.com/questions/16745/handling-growing-number-of-tenants-in-multi-tenant-database-architecture

https://dba.stackexchange.com/questions/5071/what-are-the-performance-implications-of-running-multiple-smaller-dbs-instead-of

https://dba.stackexchange.com/questions/7924/one-big-database-vs-several-smaller-ones

+0

非常感謝亞倫,你幾乎正確地迴應了我的想法。 – 2012-08-16 21:12:00

0

你的問題是一個設計問題。爲了回答它,您需要了解您要構建的系統的要求。從技術角度來看,SQL Server(或者任何數據庫)都可以處理這兩種情況。

這裏有一些事情要考慮。

第一個問題是您的客戶需要的數據是多麼獨立。在某些情況下(比如銀行的投資方和市場分析方面),將來自不同業務部門的數據混合在一起可能不合法。在這種情況下,單獨的數據庫就是解決方案。

接下來的問題是安全性。在某些情況下,客戶可能會非常不舒服,因爲他們的數據與其他客戶數據混雜在一起。一個小小的漏洞和機密信息無意中被分享。這對於同一家公司的不同業務部門可能不是問題。

您是否必須處理不同的正常運行時間要求,上傳要求,自定義以及可能與其他工具的交互?如果一個業務單位儘快需要其他業務部門不感興趣的定製,那麼就建議不同的數據庫。

另一個考慮因素是性能。這個應用程序是否使用了大量昂貴的資源?如果是這樣,能夠將應用程序分區到不同的數據庫 - 以及可能不同的服務器 - 可能是非常需要的。另一方面,如果大部分數據是共享的,並且存儲庫實際上是具有相同底層功能的中央存儲庫,那麼一個數據庫是一個不錯的選擇。

+0

謝謝戈登,我的客戶完全是不同的業務,但在同一領域,所以我認爲'分開但平等'的數據庫是答案。 – 2012-08-16 21:18:05

相關問題