為分散式環境選取適當的主索引鍵
對於參與累加同步處理的資料表而言，Sync Framework 需要每個資料列都進行唯一識別。用戶端與伺服器快照集同步處理則不需要這項處理。一般來說，資料列是使用伺服器或對等資料庫中定義的主索引鍵進行識別。在分散式環境中，選取用來做為主索引鍵的資料行類型時，必須特別小心。主索引鍵在所有節點之間都必須是唯一的，而且不能重複使用：如果刪除某個資料列，該資料列的主索引鍵不可用於另一個資料列。如果有多個節點使用一個主索引鍵，可能就會發生主索引鍵衝突。這是任何一種分散式環境都可能會發生的問題，並不是 Sync Framework 的限制。本主題描述可以在主索引鍵上進行的多項選擇，也描述這些選擇適合用於分散式環境的情形。
自動遞增 (識別) 資料行
資料庫架構設計師經常會選擇自動遞增資料行做為主索引鍵。這種自動遞增屬性 (SQL Server 中的 IDENTITY 屬性) 會為插入資料表中的每個記錄產生新值。這個新值是透過以固定數值 (遞增值) 遞增或遞減目前值 (初始值/種子) 而產生，然後將結果指派至正在插入的資料列。自動遞增資料行一般是使用壓縮資料類型，例如整數。這些可能會在查詢基礎資料表時，產生更壓縮的叢集索引、更有效率的聯結 (Join)，以及更少的 IO。
但是由於種子和遞增屬性都是固定的，而且可以從有限數目的可能值中選取，主索引鍵衝突的機率非常高。這種索引鍵適合用於僅供下載的資料快取案例。在這些案例中，伺服器或指派的對等應該是產生新主索引鍵值的唯一節點。因此，這些值在拓撲中所有節點之間保證是唯一的。如果插入作業僅發生於一個節點，則自動遞增資料行也適合用於僅供上傳和雙向案例中。在這些案例中，插入作業一般是僅發生於伺服器或指派的對等上，而上傳作業和可能進行的刪除作業則發生於一個或多個用戶端。如果您需要在多個節點執行插入作業，應該使用本主題下文中描述的其他方法。
GUID
使用 GUID (SQL Server 中的 uniqueidentifier 資料行) 做為主索引鍵可以保證在任何數目的節點之間都是唯一的，且消除可能與自動遞增資料行產生主索引鍵衝突的情形，但是在主索引鍵中使用 GUID 會有下列後果：
大型資料型別 (16 位元組) 會增加叢集索引的大小，可能會對如聯結等一般作業產生負面影響。
未排序產生的 GUID 會導致資料列插入叢集索引的隨機位置中。如此將轉而產生片段化的叢集索引。這樣可能會對查詢基礎資料表時所需的 IO 產生負面影響。
在 SQL Server 2005 及之後版本中，您可以使用 NEWSEQUENTIALID() 函式循序產生 GUID，協助消除這種片段化現象。
包含節點識別碼的索引鍵
這種做法中所使用的索引鍵是結合在伺服器端或用戶端節點的唯一值與拓撲之間的唯一值。例如在用戶端與伺服器同步處理中，您可以使用自動遞增資料行 (在節點上為唯一) 結合儲存識別碼雜湊的資料行，該識別碼是由 Sync Framework 指派給每個用戶端(這是 ClientId，在拓撲之間為唯一)。然後再建立具有這兩個資料行的複合主索引鍵。另外一種做法是，您可以開發系統來為每個插入資料列產生值，以便將資料列識別碼和用戶端識別碼包含於一個資料行中。
自然索引鍵
在此策略下，您不使用任何一種製造的索引鍵，而改用商務索引鍵，以唯一識別記錄。例如，用來儲存客戶資訊的資料表可能會使用身分證號碼做為主索引鍵值，而不使用識別資料行。這種做法的缺點是，如果需要多個資料行來識別記錄，主索引鍵可能會變得很大。而且這種組合索引鍵必須傳播至其他資料表，以支援一個或多個外部索引鍵關聯性，這些關聯性會轉而對聯結效能產生負面影響。
線上插入
如果上述方案中沒有任何一個適用，而您的案例只需在用戶端執行少數插入作業，讓應用程式直接將這些資料列插入伺服器可能是可行的做法。在下次同步處理期間，新資料列就會下載並插入用戶端。由於主索引鍵值是在伺服器上產生，所以不會發生主索引鍵衝突。