2009-11-18 101 views
3

我們有一個本地服務器,它具有訪問數據庫,該數據庫將數據提供給同一個域中的客戶端。現在,我們也有外部託管的網站,和橋系統的產品,類別和訂單等本地和遠程數據同步

產品,種類和客戶等,只能在本地添加但是,只要上傳/下載功能上的工作,訂單可以在本地和網站上添加。我們正試圖通過使用Web服務的橋接應用程序來使這些同步。我們已經有這個工作,但遇到了更多的問題。我們目前的做法是:

  • 每一個人記錄有一個本地ID(LUID)和Web服務器的ID(SUID),使用的一個例子是,當在網站上添加一個項目,它被賦予一個唯一的SUID並且luid爲-1,一旦該項目被橋接應用程序下載,就會應用並更新luid。這與本地服務器上添加的項目相反。
  • 每個單獨的記錄還有一個標誌字段(突出顯示插入,更新,刪除(從網站)和刪除)。

上面的工作很好 - 除了luid和suid方法之外,一旦下載一個項目就無法輕鬆跟蹤記錄關係。這種方法似乎只適用於單向數據 - 即僅將產品上傳到網站以供查看(並動態更新和刪除它們)。

爲了解決這個問題,我一直在使用的GUID或許梳子GUID的辦法,這意味着項目的兩面都可以被添加,並適當考慮同步,思想表現略打,使我擔心。

一些重要的點是:

  • 本地服務器是數據「大本營」這裏的一切必須是(最終)儲存。
  • 由於Web服務的原因,只有本地網橋應用程序可以向Web服務器發出請求。
  • 需要支持可能並不總是有互聯網連接的機會,所以從Web服務器請求唯一ID並不理想。

有沒有人有更好的編程方法來處理這種'同步'的意見?

回答

0

一個獨特的ID肯定會簡化事情。我不明白爲什麼你需要關注性能,GUID可以根據特定機器構建,或者ID可以分階段發佈,以便正常的構建是純粹的本地活動。

+0

我的表現擔心純粹是因爲網站在使用網站時將在聯合中使用這些GUID。你仍然覺得這不是問題嗎? – 2009-11-18 12:28:14

+0

使用GUID或您當前的ID進行比較? GUID的密鑰大小較大,因此性能較差?我的目標是對性能的影響很小,但正如所有與性能相關的事情一樣,要真正知道的方法就是衡量。做一個複雜的設計是爲了避免發生微不足道的性能開銷,這是一個非常常見的錯誤。 – djna 2009-11-18 13:15:57

+0

我可能會在GUID上進行連接,避免在同步時設置本地和服務器ID,並將它們分開關聯。我將用GUID和可疑表格大小關係進行一些性能測試。 非常感謝您的意見:) – 2009-11-18 13:44:53