扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:microsoft.com 来源:microsoft.com 2007年9月1日
关键字: 数据存储 数据库 SQL Server 2005 SQL Server
数据存储概述:
对数据进行存储有一系列的可选方案。不久以前,很多应用程序都采用各自的专有格式将数据序列化为磁盘上的平面文件。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。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者