應用程序數據同步 - 與舊版一起運行新應用程序

Question

我們正在更換舊系統。兩個應用程序一起運行將會有一段時間。用戶將能夠使用任一系統，而挑戰是能夠保持他們的數據庫彼此同步。

新系統是ASP.NET，遺留的是VB6。兩者都在SQL Server數據庫上運行。目前還不清楚數據庫是否在同一個服務器機房，更不用說同一個國家。

桌子上的兩種解決方案到目前爲止是：坐每臺機器上，並通過其他應用程序調用

1. Web服務。
   • 需要修改本地對象的基類（es？）上的Save方法。這是侵入性的，並且在關閉它時可能會成爲問題。

2. 單個窗口服務，用於輪詢每個數據庫並計算出發生了什麼變化，並根據需要轉發適應的更新。

   • 需要更改這兩個應用程序中的模式以確保它們在所有表上都有LastModified（DateTime），因此我們可以在任何給定的時間間隔執行一次定期SELECT。

這兩種解決方案看起來都是合理的。兩種解決方案都有優點和缺點。該業務要求在更新一個系統和在另一個系統中看到它之間不超過2秒的延遲（！）。這可能是一個伸展目標，但這是目標。已建議，但拒絕

其他（我願意重新考慮）是：

• 數據庫觸發器（blugrh）
• 的BizTalk或其他總線（看起來像一個大錘，是太複雜切換解決方案）
• 修改所有的存儲過程（NOOOO。）
• SSIS（不知道有足夠的瞭解這個還）

欣賞你可能有的任何想法。

編輯：模式完全不同。

Answer 1

最終，這是通過web服務解決的。它工作得很好。

Answer 2

2秒，這是一個非常緊湊的時間表，我猜你的Windows應用程序的解決方案可能只是不會削減它，而不是是否有數百個在同一時間或改變任何東西，並且投票時間必須幾乎每秒都希望使其在2以內。

數據庫是否使用相同的結構？如果是這樣，我會考慮實施複製。

編輯

的評論和添加的模式是完全不同的，我不得不說，我真的看到兩個操作的集合。

1. 修改應用中的數據存儲選項以在兩個表中進行插入/更新/刪除。優勢：即時，無需外部流程共享。缺點：必須修改所有代碼，很難禁用等。

2. 正如您所述創建同步應用程序以同步更改的數據。優點：完成傳輸後可以簡單地禁用。缺點：編寫起來非常複雜，特別是如果有大量表格。另外，速度並不快，2秒將很難完成

Answer 3

個人而言，我會拒絕用戶使用任一系統simulataneously的想法。如果用戶1在系統1上更改了記錄1，並且用戶2在系統2上以不同方式更改了記錄1，您將如何解決該問題？

此外，如果你不需要人們使用新系統，他們不會。在大多數組織中，抵制變革的能力非常強大。

我會建議您推出新系統，並要求所有人都使用它，並且每小時將數據發送到舊系統，以防因任何原因需要恢復。

我看不到合理的方法來獲得2秒鐘的同步。這是一個荒謬的要求，應該毫不含糊地告訴商業方面。

有時你只需要反擊，當企業用戶想要的東西不合理。

Answer 4

你在這裏描述的讓我感覺就像在噩夢中！我認爲你應該首先向每個人說明，在整個轉換過程中，考慮到能夠允許用戶通過2個不同的數據庫通過2個不同的應用程序更新所有數據是不可能的（或者至少非常昂貴） ！我什至不談論2秒的延遲...

據我所知，基本策略應該是逐步將數據更新權限和可能性從舊版切換到新應用程序。用戶將能夠從雙方看到數據，但只能通過其中一個應用程序進行更新。

（incidentaly，這種方法也將迫使用戶逐步切換到新的版本，避免expected and annoying resistance issue already exposed by @HLGEM）

一旦這個規則顯然是接受了，然後你可以執行以下步驟。

1. 設置允許從遺留數據庫向新數據庫傳輸數據的所有過程。我想你將需要在未來幾個月內運行幾次...
2. 設置所有程序允許以其他方式傳輸數據（反向數據傳輸）
3. 在這裏，您應該已經確定了同類的表組一起移動。合併前面的代碼的方式，你會得到這些組的每一個「數據傳輸」過程和「反向傳輸」。

然後，對於每個這些基團的

通過代碼或在數據庫級

把你的更新限制運行您「數據傳送」程序

組織您的「反向傳輸」過程作爲新數據庫中的觸發器

我猜你將能夠傳輸的第一種數據將是不包含任何外鍵的列表秒。

以這種方式工作，你會逐漸從那裏您可以

• 讀/寫遺留應用程序+只讀 新的應用程序

到

• 讀取的情況下切換 - 僅傳統應用程序+讀/寫 新應用程序。