2014-03-03 217 views
1

我正在研究一個應用程序,該應用程序將由幾個(5-8)不同的機構使用,所有這些機構都相互關聯,但作爲獨立業務運營。儘管每個機構都將使用同一個應用程序,但他們將在後端各自擁有自己的獨立數據庫。該業務已經運營了很多年,而且歷史數據需要遷移到新的數據庫中。在數據庫之間共享數據

幾乎所有的意圖和目的,這些機構的數據是不相關的。但是,我希望能夠在不同數據庫中的客戶之間建立聯繫,例如,確保某個機構的壞賬客戶不會在沒有任何警告的情況下與另一個機構開立賬戶。

我能想到的唯一解決方案是擁有一箇中央數據庫,這個數據庫比一個Person表格更小,更簡單。當在任何離散數據庫中創建新客戶端時,根據名稱和郵政編碼對該中心表執行查找,以提出可能的匹配。

如果用戶看到似乎與他們設置的客戶端匹配的現有「人員」,他們從列表中選擇匹配的記錄,並將中心表中的唯一人員ID添加到該機構自己的數據庫的客戶表。如果未找到匹配項,則首先在中心Person表中創建一條新記錄,Stored Procedure將返回新​​的Person ID,該Person ID將再次添加到機構數據庫的Client表中的PersonID列。

實際上,每個數據庫中的每個客戶端表都有一個外鍵字段,但這在數據庫中並未實際定義,因爲具有主鍵(Person表)的表位於不同的數據庫中。

這聽起來像是一個合理的解決方案嗎?任何人都可以提出更好的方法?我可以看到這種方法存在的問題,例如「如果客戶的詳細信息在其中一個機構數據庫中更新,您會做什麼?您是否向上填充了更改的內容?」但我想不出更好的選擇。

+0

您正在使用哪些DBMS?甲骨文? Postgres的? –

+0

對不起,這是SQL Server 2012. –

回答

0

更好的方法是讓整個應用程序有一個可以複製的數據庫(主 - 主複製)。閱讀here

就數據庫設計而言,更容易擁有multi-tenant體系結構,其中每個機構都使用同一個數據庫,但用institution_id進行區分。這樣,您可以確保整個組織內的用戶唯一性,同時管理架構更改更新等。

+0

我曾想過單數據庫解決方案,無論是單一模式還是多重模式,但我認爲缺點大於我的情況。事實上,我能看到的唯一好處就是能夠在客戶端之間共享數據,就像我原來的問題一樣,我只想對非常小的數據集進行分析。 –