集成来自多个站点（客户端）的数据
很多公司都有多个区域办事处或机构，这些办事处或机构收集和处理的数据必须发送到中央位置。 例如：
可以将库存数据从本地仓库中的若干个服务器合并到公司总部的中心服务器。
来自公司内部各个独立业务部门的信息可以发送到中心服务器。
来自各个分散位置的订单处理信息可以合并到一起。
在某些情况下，还会从中心站点向远程站点发送数据。 这些数据在远程站点上通常为只读数据，如只能在中心站点进行更新的一组产品库存表。
下图说明了一种数据在中心站点和远程位置之间双向流动的典型方案：
.gif "向区域办事处复制数据")
在此关系图中，数据先流向一个集线器，然后再流向该集线器所服务的区域办事处。 如果该单位没有中间层，数据也可以在中心站点和区域办事处之间直接流动。
Adventure Works Cycles 示例
Adventure Works Cycles 是一家虚构的制造公司，用于演示数据库概念和方案。有关详细信息，请参阅AdventureWorks2008R2 示例数据库。
Adventure Works Cycles 在全世界拥有众多销售办事处。 每个销售办事处都从其区域销售人员那里收集数据。 每个营业日结束后，这些数据先传输到区域集线器，然后传输到中心站点。 数据也通过集线器从中心站点向外传输到各销售办事处，使销售办事处得到最新的价格和促销信息。
此方案的一般要求
区域办事处的应用程序通常具有下列特征，适用的复制解决方案必须具备这些特征：
在中心站点和远程站点输入和更新数据。
远程用户必须能够进行独立更新，而无需连接到中心站点。
由于多个用户可能独立更新相同的数据，因此可能引发数据冲突，而冲突必须得到处理。
某些数据（例如，产品定价表中的数据）只应在中心站点进行更新。
用户应能按需同步数据或在计划的时间同步数据。
应用程序必须控制好远程站点保持不同步状态的时间。
需要对某些表进行筛选，使每个用户从一个或多个表中接收不同的数据。 例如，一个区域办事处只接收该办事处所在区域的客户的联系信息。
某些数据在站点之间传输时必须作为一个单元进行传输。 例如，如果从远程用户向中心站点发送订单，那么订单标题必须在订单详细信息之前提交。
同步数据时，应用程序可能会要求执行自定义业务逻辑。
应用程序可能会要求通过 Internet 而不是通过专用连接来实现数据同步。
业务的组织方式可以是数据通过一个或多个中间层在中心站点和远程站点之间流动（如本主题前面的关系图所示）。
下图说明了与此方案关联的筛选：
.gif "针对区域办事处应用程序的筛选")
用于此方案的复制类型
Microsoft SQL Server 使用出版业的术语来描述复制系统的组件。 这些组件包括发布服务器、订阅服务器、发布、项目和订阅。 在上图中，中心站点为发布服务器。 中心站点上的数据为发布，每个数据表都是一个项目（项目也可以是其他数据库对象，如存储过程）。 每个集线器就是发布的一个订阅服务器，接收作为订阅的架构和数据。 然后集线器重新发布数据，而区域办事处则订阅这些数据。 有关系统组件的详细信息，请参阅复制发布模型概述。
SQL Server 针对不同的应用程序要求提供了不同类型的复制：快照复制、事务复制以及合并复制。此方案最好用合并复制来实现，合并复制非常适合处理上一部分所述的要求。 有关合并复制的详细信息，请参阅合并复制概述和合并复制的工作机制。
.gif "重要说明") 重要提示 |
|---|
可以通过两种方式来实现此方案：将中心办事处作为发布服务器，并将远程办事处作为订阅服务器，或者反过来。合并复制不支持中心订阅服务器拓扑。 即使所有更改都发生在远程站点，仍要将中心办事处配置为发布服务器，而将远程站点配置为订阅服务器。 通过使用中心订阅服务器拓扑的事务复制可以实现类似的方案。 如果您的应用程序不要求能够为每个远程站点提供唯一数据集的冲突解决方法或筛选器，则可以考虑使用事务复制。 有关详细信息，请参阅集成来自多个站点（服务器）的数据。 |
与此方案相关的合并复制选项
针对本主题前面所述的要求，合并复制提供了多个选项。 下表列出了各种要求以及适用的合并复制选项。
在中心站点和远程站点输入和更新数据。
合并复制提供此项功能，无需指定任何单独的选项。
远程用户必须能够进行独立更新，而无需连接到中心站点。
合并复制提供此项功能，无需指定任何单独的选项。
由于多个用户可能独立更新相同的数据，因此可能引发数据冲突，而冲突必须得到处理。
对于可能出现数据冲突的情况，合并复制提供了冲突检测和解决方法。 最好是在应用程序设计中避免发生冲突，但在无法避免冲突时，可以选择默认的冲突解决机制（先到者有效）或者使用自定义冲突解决方法。 有关详细信息，请参阅检测并解决合并复制冲突。
某些数据（例如，产品定价表中的数据）只应在中心站点进行更新。
对于只能在发布服务器上更新的表，合并复制提供了仅下载项目。 有关详细信息，请参阅使用仅下载项目优化合并复制的性能。
用户应能按需同步数据或在计划的时间同步数据。
复制提供了两种订阅类型：推送订阅和请求订阅。请求订阅更适用于按需同步。 有关订阅类型和安排同步计划的详细信息，请参阅订阅发布和同步数据。
应用程序必须控制远程站点保持不同步状态的时间。
合并复制允许您设置订阅过期时间，以确保在特定时间内同步所有订阅服务器。 有关详细信息，请参阅订阅过期和停用。
需要对某些表进行筛选，使每个用户从一个或多个表中接收不同的数据。 例如，每个销售人员可能只接收其下属客户的联系信息。
合并复制允许您对列和行进行筛选。 行筛选器可以是静态的，也可以是参数化的。 静态筛选器仅在创建发布时应用，它会生成一个数据集。 每次订阅服务器同步时都应用参数化筛选器，它会为不同的订阅服务器生成不同的数据集。 区域办事处应用程序通常使用参数化筛选器，但也可以使用静态筛选器。 有关详细信息，请参阅为合并复制筛选已发布数据。
某些数据在站点之间传输时必须作为一个单元进行传输。 例如，如果从远程用户向中心站点发送订单，那么订单表头必须在订单详细信息之前提交。
合并复制允许您指定将一组相关的表作为一个单元进行处理。 此单元称为逻辑记录。 有关详细信息，请参阅通过逻辑记录对相关行的更改进行分组。
同步数据时，应用程序可能会要求执行自定义业务逻辑。
合并复制允许您指定在同步期间执行的代码。 此代码可响应各种事件，并对正在同步的数据具有访问权限。 有关详细信息，请参阅在合并同步期间执行业务逻辑。
应用程序可能会要求通过 Internet 而不是通过专用连接来实现数据同步。
使用 (SQL Server Compact 3.5 SP2) 时，需要通过 HTTP 或 HTTPS 连接进行数据同步。对于其他版本的 SQL Server，可以使用 Web 同步，Web 同步要求使用 HTTPS 连接。 有关详细信息，请参阅合并复制的 Web 同步。
业务的组织方式可以是数据通过一个或多个中间层在中心站点和远程站点之间流动。
合并复制可通过重新发布来满足此要求，在这种方法中，一个中心发布服务器向一个或多个订阅服务器发布数据，后者然后再将数据发布到其他订阅服务器。 有关详细信息，请参阅重新发布数据。
实现此方案的步骤
若要实现此方案，必须首先创建一个发布和一些订阅，然后对各个订阅进行初始化。 有关各步骤的详细信息，请单击下面的链接：
在对订阅进行初始化且数据开始在发布服务器和订阅服务器之间流动之后，您最好查阅以下主题，了解常见管理任务和监视任务的有关信息：