本文详细介绍了SQL Server 2005 Compact Edition 的数据存储体系结构。
适用于：
• SQL Server 2005 Compact Edition
• 数据存储体系结构
摘要:
SQL Server 2005 Compact Edition (SSCE) 为构建多种应用程序类型提供功能强大并且轻型的数据存储引擎。本文介绍了客户端应用程序和小规模服务器应用程序的数据存储问题。文章讨论了 SSCE 的功能集以及该功能集如何解决数据存储问题。全文对各种与 SSCE 相适用的应用程序体系结构进行了介绍，重点讲解了应用程序类型的属性以及 SSCE 如何满足每种应用程序类型的要求。
简介:
为应用程序选择合适的数据存储体系结构可以说是件令人望而生畏的任务。可供选择的数据存储技术非常多，并且还在日益增长。数据存储技术的选择取决于多种因素。您必须在平台要求、大小、性能、部署的便捷、数据的易访问性以及数据存储能力之间找到平衡点。
对于服务于大量用户的服务器应用程序，无疑应当选择使用 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 和合并复制都很相似的数据库到数据库同步功能，也可以选择将自己的服务端点插入同步管道中的更面向服务的同步方法。前一种方法在设置时更简单，因为它需要的自定义代码最少。后一种方法稍微复杂一些，但您可以在客户端和服务器之间插入业务逻辑，还可以针对可以打包到适当同步服务的其他数据源。 
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%，或者性能大致相当。
文章来源于领测软件测试网 https://www.ltesting.net/
