2013-06-23 79 views
2

我正在爲不同物理位置的一組用戶設計一個小型應用程序。應用程序將連接到雲中的中央數據庫(當然,在中央服務器上 - 思考雲,但不是真正的雲)。數據庫集中保存,便於中央位置的備份。我是一位經驗豐富的開發人員,連接方法,代碼和其他因素確實不是問題。C#/ SQL雲應用程序 - 不同版本的客戶端

但是,我需要允許應用程序在用戶認爲合適的時候升級到更新的版本 - 而不是任何類型的日程安排。在新的更新中,數據庫模式可能會改變。所以我會遇到用戶A下載新版本並升級數據庫的問題。用戶B,C和D在嘗試訪問數據庫時會出現錯誤,因爲表/視圖可能不存在。

我想過在同一臺服務器上維護不同的數據庫。當用戶A升級時,我們會將他們的數據庫值從DB_V1「推」到DB_V2,他們會使用那個。用戶B,C & D在決定升級之前仍然可以使用DB_V1。最終,當所有用戶從該數據庫中升級時,DB_V1都可以被刪除。

我可以想一下在雲應用程序中處理此問題的最佳方法嗎?當客戶端可能在不同版本上時,數據庫更新通常如何完成/處理?

回答

0

不幸的是,它很難,沒有銀彈。遊戲的名稱是版本控制,並且您必須支持重疊版本。您的訪問API必須進行版本控制。例如。考慮客戶端通過REST接口與「雲」進行通信。該API的根URL可能與http://example.com/api/v1.1/類似。部署新版本時,您還可以將API移至http://example.com/api/v1.2/,並在此新API中公開新功能,但也繼續支持舊v1.1。你給客戶一段時間的寬限期升級到v1.2,並且在有足夠數量的客戶升級之後的某個時候退出v1.1。 The REST API Design Handbook是一個很好的主題資源。

現在真正的問題是您的後端,即位於URL服務後面的代碼。您必須認真設計每個升級步驟,以保持與以前版本的向後兼容性。兩個重疊版本很可能會使用相同的存儲(相同的數據庫)。如果用戶使用v1.2 API添加項目,他通常希望稍後使用v1.1 API找到它,儘管可能缺少特定於v1.2的某些屬性。您的後端必須決定如何處理使用v1.1 API添加/編輯的項目的v1.2屬性(例如,默認值,NULL等)。正如我所說,這很難,也沒有銀彈。有時你可能需要咬緊牙關,不提供後備功能(V1.2添加的項目對v1.1 API客戶端不可見,即使用單獨的存儲,不同的DB)。

你的客戶直接訪問數據庫的情況如何? IE瀏覽器。沒有明確的API,客戶端直接連接到數據庫。你的成功機會顯着減少......你可以與數據庫交互使用API​​,例如。只使用的所有存儲過程。通過使用模式作爲名稱空間,您可以提供版本控制,例如。 exec [v1.1].[getProducts]exec [v1.2].[getProducts]。但繁瑣,困難,容易出錯,您可以親吻大部分開發工具嚮導,orms以及其他口哨和鐘聲。

+0

很好 - 謝謝你的回覆。就像其他任何事情一樣,我將盡最大努力在紙面和概念驗證之前對此進行規劃,然後再在現場嘗試。我想盡可能多地識別出產品出現之前的「陷阱」。感謝您的意見 - 這真的很有幫助。 –

相關問題