为应用程序的开发制定计划

当制定复制应用程序的计划时，请考虑以下问题：

• 设计应用程序以最小化冲突。如果订阅服务器需要读取数据，但不需要更新数据，则可以避免冲突。根据地理位置或商业用途对数据进行逻辑分区，可防止用户更新相同的数据值而避免发生冲突。
  
  
• 对于预期可能发生并将要发生冲突的联机/脱机应用程序，合并复制通常是您应用程序的最佳选择。合并复制允许各种冲突检测和解决策略，逐行评估更新，并产生数据汇聚。
  
  
• 建议为以读取为主、不经常更新的应用程序使用快照复制或带有即时更新或排队更新选项的事务复制。即时更新使用两阶段提交协议 (2PC)。排队更新提供解决冲突的策略，并基于事务评估更新和冲突。
  
  
• 当使用合并复制，或使用快照复制或带有排队更新选项的事务复制时，请在执行复制前确定冲突解决策略。
  
  
• 研究断开与数据库的连接将如何影响移动或脱接用户。如果用户未在订阅服务器立即看见他们执行的更新，发生了什么情况？
  
  
• 数据同步有多快？应用初始快照及周期性更新分别需要多长时间？通过在将要使用的实际网络上应用初始快照，对它进行测试。如果通过网络传输花费时间太长，请考虑使用光盘或可移动媒体设备手动应用初始快照。
  
  
• 当使用合并复制，或者使用快照复制或事务复制并允许排队更新订阅时，通过使用 identity 范围来管理 identity 值。如果创建数据分区并为各分区指派不同的标识范围，将会避免冲突的发生，因为不同的站点将使用不同的数据子集。
  
  
• 在启用合并复制或带有即时更新或排队更新选项的事务复制之前，请确保应用程序在 INSERT 语句中使用列名，因为这些类型的复制会将列添加到发布表中。如果未在 INSERT 语句中列出这些类型的复制的列名，那么将出现错误。
  
  
• 如果使用带即时更新或排队更新选项的事务复制，那么订阅服务器将无法更新 text 或 image 数据类型的值。发布可以包含 text 或 image 列，但是这些列可能只在发布服务器上进行更新。
  
  
• 注意列和行大小的上限。在快照复制或事务复制中所使用的表最多可有 255 列，且每行最多为 8,000 字节。合并发布中所使用的表最大可有 246 列，行容量最大为 6,000 字节。对合并复制的限制比对事务复制的限制严格，是因为冲突表与存储有关冲突起源及冲突的特定原因的信息的附加列具有相同的结构。因为需要另外的空间记录该冲突信息，所以最大的行大小小于事务复制的最大行大小。
  
  
• 如果具有大批量的事务，请总是将您的应用程序设计为使用存储过程修改订阅服务器上的数据，并发布存储过程的执行。