数据库选型的五大要素.docxVIP

数据库选型的五大要素面对品种繁多的数据库产品，如何才能独具慧眼，选中适合自己的数据库产品呢？众所周知，正确的评估、选型与数据库技术本身同样重要。而通常，数据库厂商都会在性能清单和技术基准表中尽量展现产品最佳的一面，对产品弱点却避免提及或进行遮掩，关于这一点，业界已经是人尽皆知了。其实在挑选和评估过程中，首要目标是选择一款能够满足甚至超过预定要求的技术或解决方案。选型的正确方法将使用户在面对众多产品时，提高其做出最佳选择的能力。数据库选型时，必须考虑以下五大因素：1.?开发要求 2.?性能/成本3.?数据库运行和管理4.?可升级性5.?总体拥有成本?开发要求?首先，需要清楚自己究竟想使用什么开发技术。例如，你是要以ADO.NET访问传统的关系型数据库？还是要以纯面向对象技术构建J2EE应用平台？又或是需要建设XML Web Services？如果你要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准（和非标准）SQL功能有多少？如果你要规划的是面向对象开发策略，那么在原计划里的数据库支持真正的面向对象吗？它是如何支持的？若有需要,它能同时提供SQL的功能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但实际上并不是直接支持的。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。?另外，你还需要确定自己的前端技术如何与后端进行“对话”。你的业务逻辑是放在客户机一端呢？还是放在服务器一端？你要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是快速应用开发（RAD）环境吗？?目前，实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,如果实现的是基于面向对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓后关系数据库。它所代表的正好是关系数据库和面向对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象逻辑操作的平台。它的出现已经为传统数据库领域带来了冲击，而在面向对象数据库方面更是广受欢迎。?性能/成本?测量数据库性能最常见的方法是TPC基准。TPC明确地定义了数据库方案、数据量以及SQL查询。测量的结果是，在特定的操作系统上，配置了特定的数据库版本，以及在惊人的硬件条件下，每项事务的成本是多少——其中的事务可以是TPC测试中定义的任何数据库操作。?从理论上来讲，这类基准旨在提供不同产品间客观的比较值。但在现实中，这些方案又有多少能准确反映并回答你在挑选技术时所存在的疑惑？其次，所有技术厂商发布的TPC基准都会超过以前发布的结果。这样，TPC基准在更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。?以笔者多年所见，只有在真实的环境中进行实际的比较测试才可以推断出数据库的预期性能及评估所需成本。常用的方法包括平衡移植，把原来的数据转移到类似硬件上的另一套数据库，然后以真实的客户端连接这套测试对象。又或是以数据产生器针对真实的数据模型，建立出庞大的数据量，再以客户端连接作测试。这种做法跟实验室中的做法的不同之处有以下几点：第一，试验中的硬件构架跟你预期的方案不会有太大的差别；第二，所测试的事务在宽度和深度方面跟未来计划的也差不太远；第三，如果是硬件条件一样，我们可以直接看出测试对象跟原来方案有着多少差异。掌握了以上结论之后，我们应该可以更精明地为所需的性能投入相应的成本。换句话说，我们将能够更准确地预测各种数据库的性能与相应的成本。数据库运行和管理??? 所有数据库都需要进行管理。数据库管理涉及以下问题：·???????? 操作任务：备份、故障切换、灾难恢复，等等；·???????? 整理系统：分段、存档；·???????? 访问控制：定义、监控；·???????? 性能：保持系统在线和优化运行；·???????? 数据库方案变更：更改数据库结构、更新索引、数据库同步。有些数据库需要比其他数据库投入更多管理资源，业界通常以一家公司必须雇用的数据库管理员（DBA）人数的多少来做比较，这是因为只有雇用足够数量的管理员才能在确保系统运行平稳的同时，又能维持数据库的完整性。 因此，在数据库选型时应考虑以下问题：·???????? 产品需要多少数据库管理员？·???????? 他们负责什么？ ·???????? 什么任务需要停机？·???????? 停机时间会有多长？·???????? 这些任务的困难/复杂程度有多大？·???????? 执行这些任务需要什么技术？·???????? 这些任务如何管理（现场还是远程）？·???????? 现在有哪些工具可以帮助完成这些任务？·???????? 所有优化措施都可行/容