SQL Server Compact（3.5）：
使用 SQL Server Compact 可以创建精简版数据库，可将这些数据库部署到台式机和智能设备中。SQL Server Compact 与其他 SQL Server 版本共享一个通用的编程模型，可用于开发本机和托管应用程序。SQL Server Compact 提供了以下关系数据库功能：可靠的数据源、优化的查询处理器以及可伸缩的可靠连接。
Visual Studio 提供对 SQL Server Compact 的开发支持。SQL Server 则提供数据库管理支持。
在将 SQL Server Compact 用作应用程序的本地数据源时，它具有以下特性。
-
SQL Server Compact 是基于文件的，这意味着连接字符串是数据库 (.sdf) 文件的文件路径。
-
SQL Server Compact 不作为服务运行。这是使用 SQL Server Compact 3.5 与使用 SQL Server 或 SQL Server Express 的主要区别之一。
-
SQL Server Compact 支持多个连接，最多可达 256 个连接。还支持在不同进程中打开连接。
-
SQL Server Compact 最大可支持 4 GB 的数据库文件。
SQL Server Compact 是基于文件的数据库，由大约 1.4 MB 的 DLL 组成。下面列出了一些您可能需要在应用程序中使用 SQL Server Compact 的应用场景：
-
在用于台式机和移动设备的应用程序中。
-
在偶尔连接的应用场景中要使用的应用程序中。
-
在需要可免费再发行的数据库时。
-
在要求的应用程序大小和内存必须较少时。
-
需要在进程中运行数据访问代码时。
sql server express2008 r2：
基于服务的数据库，是sql server的轻量版、免费版，最大数据库大小是10G，大概有100M的大小。而compact<2M。
sql server企业版则有几个G。
摘要： SQL Server 2005 Compact Edition (SSCE) 为构建多种应用程序类型提供功能强大并且轻型的数据存储引擎。本文介绍了客户端应用程序和小规模服务器应用程序的数据存储问题。文章讨论了 SSCE 的功能集以及该功能集如何解决数据存储问题。全文对各种与 SSCE 相适用的应用程序体系结构进行了介绍，重点讲解了应用程序类型的属性以及 SSCE 如何满足每种应用程序类型的要求。
单击此处下载本文的 Word 文档版本：DataArchSSCE.doc。
简介
为应用程序选择合适的数据存储体系结构可以说是件令人望而生畏的任务。可供选择的数据存储技术非常多，并且还在日益增长。数据存储技术的选择取决于多种因素。您必须在平台要求、大小、性能、部署的便捷、数据的易访问性以及数据存储能力之间找到平衡点。
对于服务于大量用户的服务器应用程序，无疑应当选择使用 SQL Server 2005。至于具体选择基于服务器的哪个版本，则取决于应用程序的规模及其针对的领域，但通过功能列表您可以很容易地确定自己需要哪个版本。此外，更改版本只是决定使用何种许可，通常不需要更改体系结构。
对于客户端应用程序或小规模服务器应用程序，选择数据存储技术稍微有些棘手。对于客户端应用程序，由于成本、复杂性、平台要求和很多其他因素，将完整的 SQL Server 2005 实例放在每个客户端计算机上是没有意义的。小规模的服务器应用程序可能不需要 SQL Server 2005 的某些额外功能，并且昂贵的许可成本也是小型项目无法接受的。对于移动设备应用程序，平台无法支持完整版本的 SQL Server。
本白皮书主要讨论使用新的 SQL Server 2005 Compact Edition (SSCE) 时所涉及的数据存储体系结构挑战、方案和解决方案。文章对 SSCE、其他 SQL Server 2005 版本以及其他关系数据库技术（包括移动设备上的 EDB 嵌入式数据库引擎）之间的异同进行了比较。
数据存储挑战
对于客户端应用程序或小规模服务器应用程序，您需要解决很多数据存储方面的挑战：
| • | 数据存储位置。如果您要构建分布式客户端应用程序，并且可以承担将数据存储于后端服务器并通过网络检索数据的费用，完全可以在服务器上使用 SQL Server 2005。如果要构建移动设备或客户端应用程序，则可能需要在客户端建立本地数据存储，以便在脱机时缓存数据。同时您可能还需要在客户端进行缓存，以避免通过网络重复检索诸如产品目录的大型数据集。对于客户端应用程序，可能只需在本地访问数据，在这种情况下，将数据存储在后端服务器上是没有意义的。 |
| • | 数据的易访问性。生产效率对于在预算内将应用程序按时推向市场来说是非常重要的。因此您应该选择那些能够轻松从存储位置读写数据的数据存储技术。 |
| • | 易查询性。功能强大的数据存储技术能够使您便捷迅速地搜索和选择单个记录或记录集合。 |
| • | 同步数据存储的能力。对于移动客户端应用程序，存储在本地的脱机数据必须要与后端数据存储保持同步。重新编写同步机制不仅容易出错，并且很耗时。因此选择的数据存储技术应当能够支持对多个数据存储的同步。 |
| • | 安全性。在存储数据时，安全性对于数据的保护来说是非常重要的，尤其对于移动设备或便携式客户端计算机更是如此。这样，一旦计算机被窃，未经授权的用户是无法访问其中存储的数据的。而且在同步数据时，对于传递中的数据也要提供一定的保护措施。 |
| • | 数据的完整性。当您对数据存储进行数据读写操作时，需要确保数据存储一致，没有发生数据损坏。事务性数据存储提供了确保完整性的机制，与非事务性数据存储相比应该更受欢迎。 |
| • | 部署的便捷。对于客户端应用程序，资源占用较少、安装过程简便是实现可支持性和可维护性的关键。客户端应用程序所需的配置也应最大程度地精简，以便将应用程序连接到数据存储。 |
数据存储概述
对数据进行存储有一系列的可选方案。不久以前，很多应用程序都采用各自的专有格式将数据序列化为磁盘上的平面文件。XML 为在文件中存储任意数据提供了一种更为结构化、更容易操作的方式，但这并未解决前一节中所述的很多问题。要解决实现强大可靠的数据存储所面临的各种挑战，关系数据库技术是目前唯一真正广泛采用的数据存储技术。
但即便您已经将目标锁定为数据库技术，仍然可以有多种选择。您需要综合其他的标准来选择合适的技术，并根据每个方案解决上节所述挑战的方法，选择合适的数据库技术。此外还需考虑数据库是以单用户客户端数据库运行还是以多用户服务器数据库运行。
在客户端应用程序中，应当将目标锁定在两种选择中的其中一个，具体取决于它是桌面应用程序，还是移动设备应用程序。如果是桌面应用程序（运行于桌面工作站、便携式计算机或 Tablet PC 之上），应考虑采用 SQL Server 2005 Compact Edition (SSCE) 或 SQL Server 2005 速成版 (SSE)。而对于运行 Microsoft Windows CE 或 Mobile 操作系统的移动设备，则可以选择 SSCE 或 EDB 嵌入式数据库引擎。
出于很多原因，SSCE 能够为大多数客户端业务应用程序提供功能强大、简单易用的解决方案。本文稍后将对这些原因给以更加详细的介绍。SSE 虽然仅用于专门的客户端应用程序，但它对于那些支持中等用户负载，同时需要功能更强、可缩放程度更高的体系结构的小规模服务器应用程序来说，也是一个不错的选择。如果设备需要本机支持，而您担心安装 SSCE 会对设备的磁盘和内存造成影响，则 EDB 可能是个不错的选择，但您需要将此方案与生产效率更高、功能更为强大的 SSCE 作一比较。
对于小规模服务器端应用程序和缓存需要，SSCE 或 SSE 都是适用的。对于将来可能需要增长和扩展的 Web 应用程序，SSE 则是更好的选择，因为与 SSCE 相比它所支持的功能更为广泛。
数据存储应用程序
应用程序的形态和大小各不相同。如前所述，大规模服务器应用程序确实需要使用 SQL Server 2005 Workgroup、Standard 或 Enterprise 版本，但这些不是本白皮书重点关注的内容。对于客户端应用程序和小规模服务器应用程序，应用程序可以划分为多种应用程序类型。这些类型包括：
| • | 现场团队应用程序。这些是移动工作人员在现场使用的客户端应用程序。这些应用程序通常运行于便携式计算机或 Tablet PC 之上，但也可以运行在移动设备上。对于客户或设备比较分散的工作环境来说，这些程序可以提供交互式数据展示和交流功能。 |
| • | 个人信息管理 (PIM) 应用程序。这些客户端应用程序用于存储和访问信息项集合，例如联系人、计划、任务、便笺等等。它们可以运行在台式机、便携式计算机或移动客户端设备上，但越来越多的这类应用程序是出于要在移动设备上实现低资源占用量而开发的。 |
| • | 小规模 Web 应用程序。这些是简单的 Web 平台客户端应用程序，用于通过 Web 向少数用户展示动态信息。例如小型企业、社区和非赢利组织或俱乐部。这些程序需要公开 Web 服务器，但要能够从桌面操作系统（例如，Windows Vista 或 Windows XP Professional）运行。 |
| • | 缓存应用程序。无论客户端应用程序是否是为脱机工作而设计的，在需要查找诸如城市、省份、邮政代码、产品目录列表等信息时，每次都执行完整的数据库往返通常是没有意义的。通过实现客户端数据缓存，可以为呈现列表或在很少更改的查找表中进行搜索提供重大的性能改进。另外，某些应用程序在设计时所使用的分布式体系结构可能涉及需要与集中后端应用程序服务器通信的智能客户端、移动设备或 Web 客户端应用程序。应用程序服务器可能需要将数据缓存在本地，以避免发生往返数据库服务器的操作。虽然需要将数据缓存在本地计算机，但不能因此就购买完整的 SQL Server 实例或承担高昂的开销将其安装于本地应用程序服务器上。 |
数据存储可选方案
要做出正确的体系结构决策，应当在正确理解可用方案的基础上客观地找出解决方案。对于体系结构的数据存储需要，要考察很多可选方案。再次强调，本文着重介绍客户端和小规模服务器数据存储。针对您体系结构内这些部分的主要可选方案有文件存储、EDB、SSCE 和 SSE。要做出合理的选择，必须研究每种方案的功能和限制，并根据需求对其进行权衡。
平面文件或 XML 文件
从简单化的角度考虑，使用平面文件或 XML 文件表面上看似乎很吸引人：大多数开发人员已经知道如何使用 Microsoft .NET 或 XML 序列化操作对文件进行数据读写操作，或使用数据集的各种功能从文件以 XML 的形式对其进行读写。但是，文件在一致性和可靠性方面存在问题。如果应用程序在没有正确完成 I/O 操作并关闭文件的情况下发生中断或被关闭，则所包含的数据可能会损坏，而文件锁定功能可能导致应用程序无法正常运行。这些问题可以通过编写符合标准的代码和错误处理来解决，但一旦这样做，最初使平面文件吸引人所依靠的简单性也就荡然无存了。
而且其内部也缺乏文件查询功能，通常必须先将文件的全部或大部分读取到内存数据结构中，然后数据才可用。因此，如果在应用程序的整个执行过程中需要对数据进行查询、读取和写入操作，则这些数据不适合采用平面文件和 XML 文件。对于诸如配置设置和首选项等简单数据，采用 XML 配置文件比较合适。另外，最好根据访问模式将较大的文档和文件存储为平面文件，而将元数据保存在数据库中。但应用程序的大多数随机访问读/写数据应当通过数据库引擎进行存储和访问。
EDB
EDB 嵌入式数据库引擎是 Windows CE 5.x、6.x 和 Mobile 6.x 操作系统自带的一部分。EDB 是一种简单的关系数据引擎，它允许用户使用有限的类型系统和查询功能存储表格数据。如果您希望使用设备上的自带功能，或者希望安装的功能在设备上占用资源最少、开销最低，则 EDB 是个不错的选择。对于某些种类的简单数据检索，EDB 可能比 SSCE 更快，但如果需要执行复杂查询操作，它可能较慢。使用 EDB 的最大缺点之一是只能通过使用 Microsoft Visual C++ 中低级别的 API 来访问它。如果要使用 .NET Compact Framework 来编写应用程序以实现使用托管代码开发所带来的生产力优势，则必须使用 C++ 编写单独的数据访问组件用以处理 EDB 数据库，然后需要通过托管代码与该组件进行互操作。这样做所带来的复杂性很可能会远远抵消使用 EDB 的优势。只有在您编写应用程序时使用了嵌入式 C++ 并且侧重于使资源占用量最小化和使应用程序性能最大化的情况下，才应当考虑 EDB。
SQL Server 2005 Compact Edition (SSCE)
SSCE 是一种轻型的 (< 2 MB)、免费的关系数据库引擎，可以安装在目前任何的 Windows 操作系统上。由于 SSCE 是本白皮书的重点讨论对象，因此在随后一节中将介绍它的完整功能集。从较高的层面上看，SSCE 支持表、关系、约束、复杂查询处理、事务、复制和数据安全性。若要为 SSCE 编程，需要使用 ADO.NET 托管提供程序，其数据访问编码模式与用于其他托管提供程序（例如，SQL Server SQLClient 托管提供程序）的模式类似。还可以使用 OLE DB 从非托管客户端访问 SSCE。SSCE 作为一组通过使用应用程序进行引用的库在进程中运行，很容易用应用程序库或作为单独的 MSI 安装来部署它。SSCE 可以很方便地用 ClickOnce 应用程序进行部署，或者通过 Xcopy 部署到移动设备上。SSCE 还将预安装在 Windows Mobile 6.0 或更高版本上。
SSCE 类型系统是 SQL Server 2005 类型系统的子集，并非支持完整 SQL Server 实例所支持的所有功能。SSCE 不支持的 SQL Server 用于服务器应用程序的常用功能包括存储过程、触发器、视图、函数、用户定义的数据类型以及参与 SQL Server Service Broker 消息传递的功能。
SQL Server 2005 速成版 (SSE)
SSE 是一种资源占用量相当少的 (< 55 MB)、免费的数据库引擎服务，它可以安装在目前任何桌面机或服务器的 Windows 操作系统上。由于 SSE 作为一项 Windows 服务运行，因此它需要目标计算机安装 Windows Installer (MSI)。SSE 可以通过 ClickOnce Bootstrapper 进行部署，以允许通过 ClickOnce 部署的应用程序使用它。SSE 支持用户实例隔离，该功能通过确保将一个用户的数据与其他用户的数据自动隔离，从而方便 ClickOnce 部署。
SSE 支持完整 SQL Server 实例的大多数功能，包括表、视图、存储过程、触发器、函数和 SQL CLR。从托管代码访问 SSE 实例中的数据与从完整 SQL Server 实例访问数据的方式相同，都要使用 SQLClient 托管提供程序。还可以通过使用 OLE DB 提供程序，从非托管应用程序访问它。
与完整 SQL Server 实例相比，SSE 的限制相当容易理解。SSE 只使用计算机的一个处理器（即使存在多个处理器）；它只使用 1 GB 内存；并且它只允许数据库大小增长到 4 GB。另外，对于所有类型的复制，SSE 可以是订阅者但不能是发布者，只要 SQL Server Service Broker 消息是通过完整的 SQL Server 实例传递的（就是说，在传递链中 SSE 实例之间除了完整实例以外没有对等消息传递），它就可以发送和接收该消息。
SQL Server 2005 Compact Edition 概述
在概念上，可以将 SSCE 视为 SQL Server 2005 数据库引擎的高度精简版本。但是，它是单独的数据库引擎，旨在使驻留应用程序的磁盘、内存和安装要求最小化，同时最大程度提供简单、安全和事务性关系数据存储所需的关键功能。
SSCE 历史
SSCE 的起源可以追溯到 2001 年发布的 SQL Server CE 1.0，这是 Microsoft 针对移动设备操作系统发布的第一个关系数据引擎，它基于 SQL Server 2000 数据库功能。后续版本 1.1 和 2.0 改进了用户体验，并且 2.0 提供了与 .NET Compact Framework 应用程序的集成。SQL Server 2005 Mobile Edition 作为下一代移动数据库引擎与 .NET 2.0 和 SQL Server 2005 一起发布。SQL Server 2005 Mobile Edition 提供了很多新功能，可靠性更高，性能更为强大，同步选项更加合理，并且能够与 SQL Server 2005 和 Microsoft Visual Studio 2005 更好的集成。
当 SSCE 在 TechEd 2006 上首次发布时，此版本的新名称为 SQL Server 2005 Everywhere Edition。第一次发布后仅过了很短时间，Microsoft 即优化了 SSCE 的计划和版本功能，并于 2006 年 11 月在 TechEd Europe 2006 会议上发布了这些内容和新名称。因此，您可能会发现 Web 上的某些材料在短期内还会使用旧名称 SQL Server 2005 Everywhere Edition 或简称 SQL Everywhere，对于这些名称，请将它们视为与 SSCE 相同。值得注意的是，与早期的 SQL Server CE 版本相比，SSCE 这一数据引擎完全不同并且功能得到了大幅增强，因此需要小心分辨它们。
SSCE 核心功能
SSCE 的核心功能是允许对事务性关系数据进行安全的访问和存储。通过 SSCE 引擎，可以执行包括数据定义语言 (DDL) 和数据操作语言 (DML) 查询的 SQL 查询。使用 SSCE，可以将数据库实例创建为单个 .sdf 文件。在该数据库中，可以定义有主键和约束的表。通过外键约束以及级联删除和更新，SSCE 支持完全的引用完整性。
另外，SSCE 支持以下功能：
| • | 多线程数据访问的多个并发连接。 |
| • | 对 .sdf SSCE 数据文件的密码保护和 128 位加密。 |
| • | 广泛的列数据类型。 |
| • | 可滚动、可更新的游标，以便快速轻松地访问已连接的数据。 |
| • | 数据库大小可以增大到 4 GB。 |
| • | 通过合并复制和远程数据访问 (RDA) 与 SQL Server 同步。 |
SSCE 新功能
SSCE 的所有核心功能实际上是 SQL Server 2005 Mobile Edition 的一部分，后者在 2005 年 10 月与 SQL Server 2005 和 .NET 2.0 一同发布。SSCE 添加了很多外围功能，这些功能使其不同于 Mobile Edition：
| • | SSCE 现在可以在任何受支持的 Windows 操作系统上运行，包括移动设备、Tablet PC、便携式计算机、台式机和服务器。 |
| • | SSCE 可以通过 Microsoft Update、Systems Management Server 或 Microsoft Windows Server 更新服务进行更新。 |
| • | 可以使用 ClickOnce 部署 SSCE。 |
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 和合并复制都很相似的数据库到数据库同步功能，也可以选择将自己的服务端点插入同步管道中的更面向服务的同步方法。前一种方法在设置时更简单，因为它需要的自定义代码最少。后一种方法稍微复杂一些，但您可以在客户端和服务器之间插入业务逻辑，还可以针对可以打包到适当同步服务的其他数据源。图 1 显示新 OCS 同步框架的体系结构。
图 1. OCS 同步框架
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%，或者性能大致相当。
用 SSCE 构建解决方案
要理解如何将 SSCE 集成到应用程序体系结构中，最佳的做法是讨论 SSCE 在本白皮书前面总结的四种应用程序类型中的使用：现场团队应用程序、个人信息管理 (PIM) 应用程序、小规模 Web 客户端应用程序和应用程序服务器缓存。
现场团队应用程序
现场团队应用程序 (FFA) 通常是在移动设备、Tablet PC 或便携式计算机（作为由多个层、服务、数据库和其他体系结构元素组成的更大分布式系统的组成部分）上运行的专用客户端应用程序。FFA 通常具有一个或多个以下属性：
| • | 它们允许用户在与后端网络（在客户位置现场、路上、机场或家中）断开连接时继续执行其工作。FFA 通常是专为偶尔连接设计的，这意味着用户运行客户端应用程序时，他们不需要有任何种类的网络连接。 |
| • | FFA 通常包括在连接和断开模式下都能并发访问和使用后端数据库中的数据的多个客户端。 |
| • | FFA 必须能够将数据从后端数据库复制到客户端数据库，以便支持脱机使用。它们还需要能够在应用程序可以连接到网络时，将已修改、添加或删除的数据记录从客户端复制到服务器。 |
| • | FFA 必须是可以使用 ClickOnce 进行部署，以便对功能以及用于本地存储的数据库进行频繁更新。 |
FFA 示例包括：
| • | 联系点 (POC) 销售应用程序，用于零售、保险、房地产、财务管理和很多其他行业。 |
| • | 用户资源管理 (CRM) 应用程序，用于通过移动设备、便携式计算机和 Tablet PC 扩展工作范围的分布式团队。 |
| • | 医疗保健提供商应用程序，用于访问医疗历史记录、保存提供商与病人的交互记录、对处方药品、实验室和诊断进行分类并从度量设备收集数据。 |
| • | 库存管理应用程序，用于涉及记录和跟踪现场物品计数和可用状态的仓储、货运部门、业务办公室管理服务、门卫服务和其他应用。 |
| • | 数据收集和度量应用程序，例如，电力公司、电信、民意调查、人口普查和投票应用程序。 |
根据客户端平台的数目和类型以及应用程序的规模，FFA 解决方案体系结构也大不相同。图 2 描绘了典型的体系结构。FFA 由涉及 PDA/电话平台、Tablet PC、便携式计算机或它们的混合的多个客户端组成。通常，它们通过受保护的 Web 服务或虚拟专用网络 (VPN) 连接连接到后端服务，以便可以通过任何可用的 Internet 连接与后端数据同步，而不必返回家庭网络。向它们公开的前端通常放在外围网络（也称为“DMZ”、“外围安全区域”和“被筛选的子网”）中，以限制被它打开的端口数目和类型，而与后端网络的连接也会受到限制。对于更大规模的应用程序，外围网络 Web 服务器可能会连接到运行业务逻辑和数据访问组件的应用程序服务器，该应用程序服务器将直接与后端数据库进行会话。
图 2. 现场团队应用程序体系结构
出于数据同步的目的，通常要采用一种更直接的途径来限制应用程序的复杂性。使用 RDA 或合并复制时，同步体系结构更像图 3 所示。在这种情况下，客户端应用程序通过 HTTP 连接到后端数据库，Internet 信息服务 (IIS) 会公开 HTTP 端点（通过该端点执行同步通信）。
图 3. 现场团队同步体系结构
若要在客户端执行数据访问，可以使用一般的断开 ADO.NET 数据访问的方法，例如，使用类型化数据集及其关联的表适配器从本地 SSCE Northwind 数据存储中读取和写入数据，如以下代码示例所示。可以看到，类型化数据集将对基本存储的所有详细信息进行抽象化，并且，如果数据位于可通过受支持的托管 ADO.NET 提供程序来访问的 SQL Server、SSE 或另一个数据存储中，则此数据使用者代码将不会发生变化。在 CustomersTableAdapter 内，SqlCeConnection 和 SqlCeCommand 对象由 Visual Studio 设计者定义，并使用标准 ADO.NET 数据访问模式对 SSCE 数据库中的数据执行所有检索和更新工作。
代码示例：使用类型化数据集执行读/写数据访问
private NorthwindDataSet LoadDataSet()
{
NorthwindDataSet nwData = new NorthwindDataSet();
CustomersTableAdapter adapter = new CustomersTableAdapter();
adapter.Fill(nwData.Customers);
return nwData;
}
private void SaveChanges(NorthwindDataSet nwData)
{
CustomersTableAdapter adapter = new CustomersTableAdapter();
adapter.Update(nwData);
}
SqlCeResultSet 还支持连接的数据访问模型，如下一个代码示例所示。在此方法中，将创建 SqlCeConnection 和 SqlCeCommand 以便检索数据行（尽管它同样适用于多行结果集）。然后，我们打开连接，并执行命令来检索 SqlCeResultSet，然后通过它执行数据记录更新。在此简单示例中，通过使用阻止来关闭了连接。但在正常情况下，如果要跨越较大代码作用范围保持连接，并且可以在不必打开和关闭连接的情况下读写数据库，则应使用 SqlCeResultSet。在该情况下，在使用结果集之后不会立即关闭连接；而会使它保持打开状态，在用它完成操作后再关闭 SqlCeResultSet。
代码示例：使用 SqlCeResultSet 执行读/写数据访问
private void UpdateCompanyName(string custId, string companyName)
{
// 建立连接，只需要 sdf 文件的路径
SqlCeConnection conn =
new SqlCeConnection(
@"Data Source ='.\Northwind.sdf'");
// 建立选择查询，在结果集里列出行的内容
string selQuery =
"SELECT * FROM Customers WHERE [Customer ID] = @CustID";
SqlCeCommand getCustCmd = new SqlCeCommand(selQuery, conn);
getCustCmd.Parameters.Add("@CustID", custId);
using (conn)
{
conn.Open();
// 把行拉进结果集，
// 使用选项来允许已连接的、随机的和可读写的访问
SqlCeResultSet resultSet =
getCustCmd.ExecuteResultSet(
ResultSetOptions.Scrollable |
ResultSetOptions.Updatable);
// 移到第一个记录
if (resultSet.ReadFirst())
{
// 得到列的位置
int ordinal = resultSet.GetOrdinal("Company Name");
// 设置值
resultSet.SetString(ordinal, companyName);
// 永久保存
resultSet.Update();
}
else // 没有匹配的
{
throw new ArgumentException("Customer not found");
}
}
}
个人信息管理应用程序
PIM 应用程序在移动平台上针对本地数据存储而运行的简单数据应用程序，目的是为了方便地访问和存储个人信息。PIM 应用程序通常具有一个或多个以下属性：
| • | 在移动平台（包括电话、PDA、Tablet PC 或便携式计算机）上运行。 |
| • | 针对应用程序数据的本地数据存储提供简单的数据输入和查找功能。 |
| • | 为了可用于移动设备，需要资源占用量最小。 |
PIM 应用程序的示例包括：
| • | 电子邮件、即时消息、联系人、任务、便条、存储和检索。 |
| • | 新闻阅读器、RSS 聚合。 |
| • | 热量计算、时间管理、锻炼日志。 |
| • | 语言教师、词汇教师、字典、辞典。 |
| • | 购物列表、CD/DVD 专辑。 |
PIM 应用程序的解决方案体系结构非常简单，如图 4 所示。它采用经典的客户端-服务器设计，其中服务器是在设备或便携式计算机上的本地数据库引擎。EDB 可以用于移动设备，但对于包括移动设备在内的任何 Windows 平台，SSCE 才是简单易用、功能强大的轻型可选方案。例如，SSCE 提供了比 EDB 更丰富的查询支持，而且在托管代码中使用 SSCE 开发应用程序更容易。
图 4. PIM 应用程序体系结构
使用 SSCE 作为数据库引擎的 PIM 应用程序可能使用 SqlCeResultSet API 来尽可能简化数据检索和存储。用于此操作的代码看起来非常像前一节中的第二个代码示例。
小规模 Web 应用程序
对于预期通信量较低的简单网站来说，如果只是为了建立动态、数据驱动的网站，则并不需要购买昂贵的服务器软件，或选择涉及数据库实例的成本更高的托管服务。SSCE 和 SSE 都为存储可用于在网页上显示内容的动态数据提供了简单而免费的方法。无论网站使用 ASP.NET 还是能够通过 OLE DB 提供程序执行数据访问的其他 Web 技术，SSCE 或 SSE 都可以提供站点页面需要的数据。
适用于 SSCE 或 SSE 的 Web 应用程序的用户数不大 - 用户总数可能比较大，但每秒并发请求数应该相当小。
可以作为 SSE 或 SSCE 候选方案的 Web 应用程序的示例包括：
| • | 用户数不大的业余爱好/俱乐部站点。 |
| • | 小型用户组组织。 |
| • | 小型企业内部的 Web 应用程序。 |
除非 Web 应用程序预期的利用率非常低，扩展到更大用户数的可能性很小，否则，对于小规模 Web 应用程序来说，SSE 通常是比 SSCE 更合适的选择。如果应用程序为每小时请求数很低的单线程 Web 应用程序（例如，每小时 < 300-500 请求），则 SSCE 或 SSE 均可以处理所需的吞吐量。
但是，随着应用程序复杂性的增长和/或每秒请求数的增加，SSE 提供了更强大的可选方案，以便不断扩大应用程序的规模来满足与日俱增的需求。正如本文前面所述，SSE 支持存储过程、函数和其他企业级功能，这可以将复杂应用程序的体系结构分成更多层，各个结构之间的相互影响更小。另外，由于 SSE 作为服务运行，因此可以从同一计算机甚至不同计算机上更好地支持来自多个 Web 应用程序的并发访问。在 SSE 中，基于角色的安全性有更多选项，并且可以无缝升级到 SQL Server 完整版，即不必更改数据访问代码，因为 SSE 和 SQL Server 使用相同的数据提供程序。而且，SSE 和 SQL Server 的文件格式是相同的，因此，SSE 数据库正好可以附加到完整 SQL Server 实例，并且可以立即运行。从 SSCE 切换到 SSE 或 SQL Server 完整版时需要进行数据迁移，由于 SSCE 使用与 SSE 或 SQL Server 不同的数据提供程序，因此还需要重新编写某些数据逻辑的代码。
如果选择让 Web 应用程序使用 SSCE，则必须进行某些配置才能允许 SSCE 驻留在 Web 应用程序进程中。
缓存应用程序
缓存应用程序可以是客户端应用程序，也可以是应用程序服务器应用程序，这种应用程序需要保留查找值或很少更改的数据的本地数据缓存，从而避免对后端数据库进行不必要的往返操作。缓存用于使应用程序可以从本地计算机检索需要的数据，以便改进性能并减少网络流量。当需要对用于呈现（下拉选择或引用列表）或用于查找业务逻辑中的应用程序服务器的相对静态数据记录列表进行访问时，需要使用缓存应用程序。
为了对数据进行最快速的检索，可以将数据缓存在内存中，在需要缓存的值时直接返回数据。但是，您可能不想或不能在应用程序每次重新启动时从服务器刷新缓存，因此可能需要为缓存值提供本地数据存储。另外，如果正在缓存的值列表非常大（例如，产品目录），您可能不想将整个目录保存在应用程序内存中，因为偶尔才会需要访问集合中的项目。不论是出于哪个原因，将 SSCE 作为本地数据缓存存储位置对于您的体系结构可能都是个很好的选择。
第一次运行应用程序时，需要从服务器对缓存数据进行初始化，缓存数据通常有与它关联的过期日期或时间，这时必须从数据源刷新缓存。与缓存关联的超时取决于应用程序要求、数据的更改频率以及应用程序和用户可以容忍缓存数据的延迟时间。
在设计应用程序如何使用数据缓存时，必须选择采用被动还是主动的数据缓存策略。如果使用“被动缓存”，则应用程序将尝试从本地数据缓存获得需要的数据。如果数据不存在，应用程序逻辑会从服务器中检索数据，并将结果存储在缓存中，供后续检索使用。当缓存由于超时或其他条件而变为无效时，应用程序必须从数据源刷新缓存。如果使用“主动缓存”，则会根据某些条件（例如，从服务器定时刷新）主动更新缓存。使用主动缓存策略时，应用程序代码将更简单，因为它始终可以直接引用本地缓存中的数据。但是，必须编写额外代码才能初始化主动缓存，并使它保持最新。
对于缓存应用程序，可能要执行两级缓存。您可能需要在持久性存储（例如，SSCE）中缓存数据，从而使缓存的数据驻留在本地计算机中，以便在应用程序重新启动后仍然有效，或避免将所有缓存数据加载到内存中。但是，您可能还要将某些数据从持久性缓存内缓存到内存中，以便在需要数据时可以尽可能最快地检索数据（例如，用于驱动文本框或下拉列表输入控件中的自动完成逻辑）。对于这两个缓存级别，可以有相同或不同的缓存策略（主动对被动）。
图 5 显示示例缓存应用程序体系结构，缓存同时位于客户端应用程序和中间层应用程序服务器中。客户端应用程序在持久 SSCE 存储和内存中都缓存数据，因为在客户端应用程序中通常不用担心内存消耗量。应用程序服务器缓存将持久存储大型查找列表（例如，产品目录），不是为了避免由于可伸缩性原因而消耗内存，而是为了避免在需要查找产品目录从而获取某些数据（例如，查找某个价格范围内的所有产品）时，因往返访问数据库服务器而影响性能。缓存应用程序和执行同步的应用程序（例如，现场团队应用程序）之间的主要差异是：在缓存应用程序中，只从服务器将数据拉入本地数据缓存中。如果进行同步，则在完成编辑之后，还会将缓存中的数据与后端数据库同步。
图 5. 缓存应用程序体系结构
结论
很多应用程序都需要可靠、事务性、持久、高效的数据存储，但并不一定需要 SQL Server 2005 提供的全部功能。SSCE 提供了免费、功能强大而且容易使用的数据库引擎，它可以广泛用于各种应用场合和体系结构中。它可以用于现场团队应用程序、个人信息管理应用程序、小型 Web 应用程序或应用程序数据缓存。它提供了很多目前已有和新出现的数据同步选项，使其可以成为使用后端 SQL Server 2005 数据库的更大型分布式应用程序体系结构的一部分。SSCE 应当是任何需要轻型关系数据存储的应用程序的备选数据库技术之一。
作者简介
Brian Noyes 是 .NET 体系结构和设计咨询培训公司 Idesign (http://www.idesign.net/) 的首席架构师。他是 Microsoft 区域主管、Microsoft 最有价值专家 (MVP) 和国际知名的作家和演说家。他的新书《Smart Client Deployment with ClickOnce》（Addison Wesley .NET 开发系列的一部分）将于 2006 年 12 月发行。他的前一本书《Data Binding with Windows Forms 2.0》继续排在最佳畅销书排行榜中。您可以通过 brian.noyes@idesign.net 或他的博客 (http://www.softinsight.com/bnoyes) 与他联系。
有关详细信息，请访问：