SQL2005 CompactEdition数据存储体系(4)

SSCE 的数据同步:

在将 SSCE 用作分布式应用程序体系结构中客户端或中间层应用程序的本地数据缓存时，通常需要能够将 SSCE 数据库与后端数据库服务器同步。最初可能需要从后端数据库填充 SSCE 数据库表，并且还可能需要能够将更新的或新的记录从客户端推送到服务器数据库。

使用 SSCE，将有很多同步选项。有两个内置的同步选项：合并复制和 RDA。这两个功能都允许您双向同步数据：从 SSCE 数据库向 SQL Server 2005，或通过 HTTP 向 SQL Server 2000 数据库。除了这些功能以外，您还可以通过调用自己公开的 Web 服务端点来实现自定义同步解决方案，从而可以在服务器端通过自定义业务逻辑层双向传递数据。而且，即将发布的下一版 Visual Studio（代号为 Orcas）中将有称为偶尔连接系统 (OCS) 同步框架的新同步子系统。

合并复制是功能最强大的内置同步选项，因为它允许同时在客户端 (SSCE) 和服务器 (SQL Server) 数据库上自主而独立地更新记录。SSCE 作为订阅者参与合并复制，并且可以订阅由 SQL Server 2000 或 SQL Server 2005 公开的合并复制发布。由于合并复制还支持服务器端的冲突检测和解决机制，因此它可以轻松地响应很多客户端。合并复制的设置稍显复杂，它需要服务器端具有特定的数据库设计功能和配置。

RDA 是最易于使用的内置同步选项。使用 RDA 时，对服务器端数据库没有特定要求。若要与 RDA 同步数据，需要将整个结果集从服务器端拉到 SSCE 数据库中，以便用服务器的当前数据对表进行初始化。然后，可以在您选择同步时将更改（插入、更新和删除）推回服务器。若要获得自从最初拉入数据以来在服务器端所做的更改，则必须再次拉入同一结果集（在推送更改以便所拉入的数据包含更改之后）。RDA 没有任何并发冲突检测或解决机制。因此，如果通过应用程序（多个客户端可以同时修改不同记录）使用 RDA，则最后一个客户端写入记录的更改可以覆盖另一个客户端的最近更改（后进有效）。

发布 OCS 同步框架时，您可以选择与 RDA 和合并复制都很相似的数据库到数据库同步功能，也可以选择将自己的服务端点插入同步管道中的更面向服务的同步方法。前一种方法在设置时更简单，因为它需要的自定义代码最少。后一种方法稍微复杂一些，但您可以在客户端和服务器之间插入业务逻辑，还可以针对可以打包到适当同步服务的其他数据源。

OCS 框架为面向服务的数据同步提供了可直接使用的解决方案，而且提供了许多可扩展点以便对同步过程进行更显式的控制。客户端通过同步提供程序进行调用，以执行数据的同步。如果需要，提供程序可以调用自定义逻辑，例如验证逻辑。然后，同步提供程序通过同步代理调用服务器上的同步服务。所公开的服务可以是框架提供的服务，也可以是您公开的自定义服务。该服务通过接收端的同步提供程序进行调用，还可以调用自定义逻辑。通过合适的同步适配器及其关联的数据库命令对同步进行调度。适配器和命令的体系结构与和 ADO.NET 2.0 类型化数据集相关的 TableAdapter 的体系结构类似。

SSCE 并发:

SSCE 允许建立从同一应用程序（甚至是同一计算机的多个应用程序）到同一数据库（.sdf 文件）的多个连接。这样，您就可以更自由地根据需要构建应用程序（例如，用户可以在与后端数据库进行同步的同时继续与数据交互），或者让同一计算机上的多个应用程序共享 SSCE 数据存储。事务性并发锁定是由数据库引擎执行的，目的是防止并发连接同时访问同一记录。从技术上看，单个数据库的最大并发连接数是 256 个，但从实际性能角度来看，连接最好限制在 70-80 个。

SSCE 安全性:

SSCE 不支持基于角色的安全性和权限。SSCE 数据库的预期用途是充当在客户端计算机上执行本地数据存储和访问（或在应用程序服务器上执行简单的持久性数据缓存）的简单数据存储机制。因此，由于需要使数据库引擎尽可能小和尽可能快，所以不会考虑包括表级别的基于角色的安全性和权限。通过密码保护访问，可以强制对整个数据库进行访问控制。当数据存储在磁盘上时，可以通过加密数据库轻松地实现数据保护。

SSCE 非托管代码访问:

SSCE 还允许用户轻松地从非托管应用程序访问数据存储。SSCE 包括 OLE DB 提供程序，以便使用 Microsoft Access、Microsoft Visual Basic 6、C++ 或其他形式的非托管代码的应用程序仍然可以访问和使用已放入 SSCE 数据库中的数据。例如，这有助于从非托管应用程序和旧数据存储递增地迁移到 SSCE 和托管代码。

SSCE 性能:

SSCE 在本文档所述的所有使用情况下都表现出非常良好的性能。如果将 SSCE 性能与 SSE、EDB 或 Microsoft Access 进行比较，没有哪个产品可以在所有使用情况中都明显领先其他产品。根据查询大小、存储模式和其他变量的不同，某个产品的性能可能看起来会好于其他产品，但我们可以一致地衡量几个趋势。

如果将 SSCE 与 SSE 进行比较，我们可以从性能测试中看到几种模式。在 SSCE 中，事务的开始和提交比在 SSE 中略快，但差别不大 (20 %)。对于插入大量行 (> 100) 的参数化查询，SSCE 快于 SSE；但如果插入单行或少量行，则 SSE 更快。使用 SqlCeResultSet 的连接模型时，对于单行选择，SSCE 比 SSE 大约慢一倍；100 或更多行时，两者相当。但是，使用 SqlCeConnection API 时，由于启动和关闭存储引擎需要大量开销，因此在 SSCE 中第一次打开和最后关闭要比 SSE 慢很多（在某些情况下 > 1000 倍）。获得更好性能的优化措施是在事务之前打开 SqlCeConnection，并在最后关闭。在这种情况下，性能与 SqlCeResultSet API 相当。

如果在设备上将 SSCE 的性能与 EDB 进行比较，则在某些情况下（例如，确定数据库大小和执行插入或更新），EDB 可以快很多（100 % 或更高）。但是，在大多数搜索和查询操作中 SSCE 速度都快 20-30%，或者性能大致相当。