從其他數據庫訪問數據-系統架構

Question

我有一個我們最近開發的系統-基於SQL Server數據庫的Web應用程序。 SQL Server數據庫已設置為“多租戶”數據庫，我們網站的許多不同“安裝”都訪問同一數據庫。

我們還有另一個運行類似的應用程序，主要區別在於它有許多不同的“安裝”都訪問各自的數據庫。

所有這些網站都在同一服務器上運行，並且所有數據庫都位於同一SQL Server實例中。

我們的每個客戶都將擁有這些系統中的每一個，並且到現在為止，我們已經在這兩個系統之間進行了相當輕量的集成，這已經通過Web服務調用進行了處理。

現在，我們進行了一項新更改，要求我從多租戶系統返回數據列表，但要根據另一個系統的數據庫中存儲的條件對其進行過濾。 我可以看到幾種方法，但是想知道是否有人有什么好主意：

1. 再次提供Web服務-不喜歡這個想法，因為它意味着獲取數據列表並為每個單獨的項目打電話，這既緩慢又丑陋。

2. 在數據庫層中編寫一些動態SQL以在.dbo.table上進行聯接，這也有些難看，並且可能難以維護。

3. 將數據從一個數據庫復制到另一個數據庫。 這是我趨向於的方向，但是接下來就有數據不同步的風險。

我想對我的多租戶數據庫中的視圖做些聰明的事，但是我不想每次我們為第二個系統創建新數據庫時都必須創建一組單獨的視圖...

Answer 1

根據業務規模，我選擇#1或#2 。

#1更具可伸縮性，對異構客戶有利，但難以實施和維護。 由於您沒有公共API，因此可以轉到#2 。

#2需要專業的DBA並且非常容易出錯

#3是IMO最糟糕的解決方案，因為會發生冗余，以后很難解決。

我建議的是短期計划和長期計划。 短期使用#1或#2 ，同時重新設計數據庫。 然后，您可以將新數據模型添加到系統中，並且可以與舊數據庫共存。 當您確定其功能時，請切換到新的數據庫，但仍保留lgacy系統。 最后，當一段時間后新數據庫沒有問題時，從電路中退出舊數據庫。

Answer 2

不要更改數據模型。 有風險。 只需對其做另一個抽象包裝。

您可以在另一台服務器上復制數據庫，並讓該新包裝器處理數據副本。 如果發生任何數據損壞，只需還原到主副本即可。