SQL Server 2005 Compact Edition 的数据存储体系结构

核心提示： 数据存储可选方案 要做出正确的体系结构决策，应当在正确理解可用方案的基础上客观地找出解决方案，SQL Server 2005 Compact Edition 的数据存储体系结构(5)，对于体系结构的数据存储需要，要考察很多可选方案，这样做所带来的复杂性很可能会远远抵消使用 EDB 的优势，

数据存储可选方案

要做出正确的体系结构决策，应当在正确理解可用方案的基础上客观地找出解决方案。对于体系结构的数据存储需要，要考察很多可选方案。再次强调，本文着重介绍客户端和小规模服务器数据存储。针对您体系结构内这些部分的主要可选方案有文件存储、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。