用於同步桌面應用程序的數據庫設計

Question

我正在構建將在多臺筆記本電腦上運行的桌面應用程序。無論用戶何時回到辦公室並再次訪問，它都需要同步到中央數據庫。

我最大的問題要克服的是如何設計的數據庫，因此，它很容易與中心數據庫服務器同步。其中一個主要障礙是試圖確定如何處理密鑰，以防止它們在將要使用的多臺筆記本電腦數據庫中重複使用。

例如，假設筆記本電腦1輸入一個名爲「客戶A」的新客戶 - 使用唯一的ID，可能會分配一個客戶ID爲20.筆記本電腦2輸入「客戶C」 - 它也可以分配ID 20給那個顧客。當需要同步時，客戶A & C將在服務器上以重複ID結束。

有沒有人有與此類似的有一個優雅的解決方案的應用程序的工作？

Answer 1

替代有：

• 範圍IDS的，這是難以實現和執行。他們很難管理，很難提供一個新的網站/範圍，更難以應對退休的網站/範圍。
• 組合鍵，（網站ID，ENTITYID）比範圍更好，但需要前期設計，因爲沒有指定在所有指標中最左邊的鍵（網站ID）是可能會導致對聚集多個/所有站點（DWS中心）查詢問題。
• 的GUID。從理論上講，它們是完美的，因爲它們保證了獨特性（它們可能在理論上有衝突，我還沒有看到真正的指導衝突）。實際上，由於大小（16字節）和碎片，它們是非常差的羣集密鑰選擇。儘管如此，它們比組合鍵方法更容易得到。

Answer 2

我不知道這是一個「優雅」的解決方案，這個非常不雅的問題。 Remus有很好的想法，也建議你閱讀複製。

你也更好地設計了一個重複刪除過程，因爲無論什麼情況下，代理A會在客戶A中上升，代表b也將投入到客戶A中，並且因爲它們來自不同的來源，鍵，它們將是不同的記錄。

Answer 3

使用的GUID（又名uniqueidentifier）爲您的主鍵，和你所有的問題，複製將消失。使用Guids的懲罰幾乎總是被自動增量int PKs的支持者誇大其詞。他們所需要的額外大小（16字節，而對於int，則爲4字節）是如此微不足道，以至於我對它在討論這個問題時感到驚訝。的查詢JOIN上Guid的PK將比的查詢JOIN上int的PK運行速度較慢，但​​它不是一個訂單的數量級（即10X）速度較慢。你的結果可能會有所不同，但我發現Guid JOIN查詢的執行時間延長了40％左右（這可能看起來像是一個很大的懲罰，直到你記得摩爾定律）。

使用的的PK的GUID也讓你出去幹什麼真正哈克的東西，當你插入相關數據。不必插入子記錄，然後在插入父行之前檢索剛剛插入的行的ID，只需使用Guid.NewGuid()創建客戶端的所有ID即可。

我和複製系統工作之前，int的PK是用來分配範圍來解決這個問題，但我絕不會永遠再次做到這一點。