我有一個客戶端正在使用的桌面應用程序，每個客戶端都可以訪問其自己的本地網絡數據庫。 我的經理已經決定最好把這些數據庫合併起來，只有一個。然後，所有客戶端都將通過位於雲端的Web服務訪問該數據庫。在我們繼續做出這個決定之前，我想先權衡利弊。 我們擁有的一個選項是在每個表中都有一個ClientID，這將導致每個表都有一個組合鍵。將多個數據庫合併爲一個
我聽說另一種選擇是使用模式。請告訴模式方式如何工作，並且這是與每個表中具有組合鍵相比最好的方式。 謝謝。
這是一個非常困難和耗時的任務。您將需要進行廣泛的迴歸測試，因爲事情破裂的風險是巨大的。
讓我告訴你一個客戶端的故事，它有一個單獨的數據庫在一個單獨的服務器上，並與另一個包含許多客戶端的數據庫合併。花了幾個月時間才能完成所有的數據轉換。一切看起來都很不錯，它被推動了。不幸的是，開發人員錯過了一個需要引用客戶端ID的地方（它通常不在舊代碼中，因爲它們是服務器上唯一的客戶端）。在生產的第一天，一個發送電子郵件的過程不僅將客戶專有數據發送給客戶銷售代表，還發送給許多競爭對手的銷售代表。在所有可能錯過改變的地方，這是最糟糕的一次。它不僅損害了我們與第一個客戶的關係，而且損害了所有客戶錯誤地獲得了其他客戶信息的客戶。
還有一個遷移數據的問題，單獨的項目（無需更改應用程序所需的代碼）需要幾個月的時間，然後您已經考慮到客戶端會隨着您的需要添加數據，最終由於新數據的推動可能會遇到意外打嗝。您可能還必須至少在一個週末關閉odl系統才能進行生產更改。
使用模式不會讓它變得更容易，因爲您必須調整代碼以便爲每個客戶端創建正確的模式。而當你改變某件事情時，你必須爲每個單獨的模式改變它，所以它往往會使數據庫更難維護。
雖然我非常喜歡在一個數據庫中擁有多個客戶端，但當您沒有從頭開始時，更改風險和代價非常高昂。除非我有這些東西，否則我不會這麼做：
Code in source control
Extensive Unit and regression tests
Separate dev, QA and prod environments
A process for client UAT testing
Extensive knowledge of how cloud computing and webservices works (everyone I know who has moved stuff to the cloud has had some real gotchas)
A QA department
Six months to one year time frame for the project
At least one senior data analyst on the team.
這裏有很大的安全隱患，在您開始技術實現之前，可能需要您的客戶端合同的附加條款。然而，要評論您的問題，您可以將用戶帳戶綁定到架構上，而不是比行ID更乾淨。 – toddsonofodin