Int自動增量主鍵和GUID列

我有一個現有的數據庫，其中大多數表具有int主鍵（自動增量）。Int自動增量主鍵和GUID列

我們現在是在我們現在需要使用DB作爲一箇中央存儲，並允許其他客戶端在連接和同步數據（上傳/下載數據）

與主鍵是一個自動遞增的位置關鍵我知道存在主鍵衝突的問題。

所以我想我可以添加一個全局鍵到同步表 - 說一個GUID。

，然後創建一個自定義同步邏輯查找此GUID /比較客戶端

這聽起來好像是個好主意？對於實現同步框架的任何其他建議，在中央數據庫中幾乎不能更改（無主鍵更改）

2011-07-18 TheTiger

一般來說，一個自動遞增的鍵將不碰撞;實際上，我不確定如何實現它（因爲SQL中的大多數定義都包含「唯一」約束）。不過，您可能會遇到'重複密鑰錯誤。爲什麼讓外部供應商指定你的內部密鑰是什麼？接受他們完成的記錄，並自行生成密鑰。如果您的鍵用完了，請增加列的大小（很長）。你可以生成一個新的GUID列，但是你可能仍然會生成GUID，所以會有什麼不同？ –

那麼，因爲他們將在一個斷開的環境，即在他們有自己的數據子集的副本和添加記錄的能力的移動設備上 - 如果添加或更新記錄，我需要一種方法來匹配記錄 - 考慮將GUID用於匹配和同步過程的原因。 – TheTiger

雖然我仍然需要一個匹配的過程，也就是說我需要給客戶提供一些記錄 - 一個ID（不能使用INT，因爲它可能會發生衝突）我有1000多個潛在客戶端，他們都在自己的子集上進行插入，並將其連接到中央數據庫（同時中央數據庫也在其上直接插入數據） – TheTiger

-1

一般而言，自動遞增鍵不會相互衝突;實際上，我不確定如何實現它（因爲SQL中的大多數定義都包含唯一約束）。不過，您可能會收到duplicate key錯誤。爲什麼讓外部供應商指定你的內部密鑰是什麼？接受他們完成的記錄，並自行生成密鑰。如果您的鍵用完了，請增加列的大小（很長）。你可以生成一個新的GUID列，但是你可能仍然會生成GUID，所以會有什麼不同？

通常，數據庫中的大多數表格都會有多個「唯一」鍵。這些是「自然」鍵 - 組成一組獨特數據的實際列;不幸的是，這可能最終成爲整個表格的寬度（這就是爲什麼使用id列）。另外，除非有一些奇怪的用例，否則不要讓服務器知道客戶端ID - 讓客戶端知道服務器ID，並在客戶端的單獨列中（如有必要）跟蹤它。然後可以在上傳之前擁有自己的內部ID，這些ID與您返回的密鑰沒有關係 - 而且它們從不與服務器共享。

服務器ID是什麼並不重要（基於int或GUID），雖然我建議堅持你擁有的任何東西。無論何時客戶給你一行放在服務器上，將它們從服務器上取回生成的ID。這可以防止客戶嘗試插入已經使用的ID以及相關問題（您如何知道他們提供給您的ID不應該由其他設備生成？）。我要說的是，客戶沒有得到決定在服務器上的內部編號

編輯：

在一些快速的研究複製的光（響應HLGEM），並重新讀取原來的問題;我最初的問題是詢問如何讓客戶指定內部主鍵（這仍然很糟糕），和/或用GUID替換主鍵。儘管您的確切需求可能不需要，但添加客戶端可以填充的額外GUID列將會起作用。一些建議：
1）將GUID列上的唯一密鑰違規（意外或惡意）視爲業務例外，而不是系統例外。我可能會建議告訴客戶重新生成GUID並重新提交（默默）。 2）客戶端從來沒有獲取指定數據庫中的acutal主鍵列值。事實上，如果您使用GUID列，客戶可能永遠不需要知道它們。

來源

2011-07-25 15:59:35

我相信他們會在OP提供的場景中發生碰撞。 – HLGEM

......我明確指出，客戶不應該專門指定服務器ID來避免收集。如果他們試圖重複使用獨特的自然鍵，那是一個* business *問題，而不是* system *問題，並且應該這樣解釋。 –

我進入了使用Microsoft Sync Framework的工作，並在同步過程中將同步表中的列guid與現有的auto int主鍵一起添加到sync表中。這工作得很好 - 同步框架根據GUID進行對象匹配 - 而現有的數據庫代碼仍然照常運行，因爲我們仍然有自動增量鍵 – TheTiger

你應該看看複製。我不知道這是否會對你的案件有所幫助。但是複製通常使用GUID進行設置。

來源

2011-07-25 16:19:23 HLGEM

Int自動增量主鍵和GUID列

回答

相關問題