资料：选择数据库产品的5个因素
　　要选择一款能够满足甚至超过预定要求的技术或解决方案，一般需要考虑开发要求、性能/成本、可升级性、数据库运行和管理以及总体拥有成本这五方面因素。

　　开发要求
　　首先，需要清楚自己究竟想使用什么开发技术。例如，是要以ODBC使用.Net，还是要以面向对象技术使用Java?
　　如果您要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准(和非标准)SQL功能有多少?
　　如果您要规划的是OO开发策略，那么数据库支持真正的面向对象吗?它是如何支持的?使用什么标准?在SQL方面，您需要什么功能?数据库支持这个功能吗?有些关系型数据库虽然声称支持对象开发，但实际上并不直接支持。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。
　　另外，您还需要确定自己的前端技术如何与后端进行“对话”。您的业务逻辑是放在客户机一端呢?还是放在服务器一端?您要使用哪些脚本语言?它们与后端服务器的兼容性如何?它们是快速应用开发(RAD)环境吗?

　　性能/成本
　　测量数据库性能最常见的方法是TPC基准。TPC定义了数据库方案、数据量以及SQL查询。它指出，在这一数据库版本、平台、操作系统版本，以及这一内存和磁盘技术/容量条件下，每项事务的成本是多少??其中的事务可以是TPC测试中定义的任何数据库操作。
　　理论上讲，这类基准旨在提供不同产品间的比较值，而在现实中，方案定义可能无法准确反映您正在挑选技术的使用本质情况。其次，所有技术厂商发布的TPC基准都会超过以前发布的结果。这样，TPC基准更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。
　　另外，您也可以请求在真实的生产环境中进行实际的比较测试，并且该环境应尽量贴近您自己的生产环境。虽然完全复制自己的环境不太可能，但您应该能够据此推断出产品的预期性能。
　　最后，在最终接受产品之前，应该以真实的环境对选中的技术执行实际测试或概念验证，这一点尤其重要。

　　数据库运行和管理
　　所有数据库都需要进行管理。主要涉及操作任务、整理系统、访问控制、性能、数据库方案变更等问题。
　　有些数据库比其他数据库需要更多的管理，它通常以一家公司必须雇用的数据库管理员(DBA)人数的多少来体现，这是因为只有雇用足够数量的管理员才能在确保系统运行平稳的同时，又能维持数据库的完整性。涉及的问题包括:
　　●产品需要多少数据库管理员?
　　●他们负责什么?
　　●什么任务需要停机?
　　●停机时间会有多长?
　　●这些任务的困难/复杂程度有多大?
　　●执行这些任务需要什么技术?
　　●这些任务如何管理(现场还是远程)?
　　●现在有哪些工具可以帮助完成这些任务?
　　●所有优化措施都可行/容易执行吗?
　　如果您想创建总体拥有成本模型和确定部署后可能产生的开支，那么这些问题的答案至关重要。
　　可升级性
　　随着对数据库应用软件使用的不断增加，很可能某一时刻当前的硬件配置就不够用了，这时您就需要对硬件进行检查。升级可以朝两个方向发展:垂直升级(使用更大/更多的处理器)和水平升级(使用与当前平台同一规格的更多的计算机/处理器)。
　　在考虑可升级性时，应提出以下问题:
　　●业务逻辑能和数据分离吗?
　　●业务逻辑能拆分吗?
　　●数据库能分段吗?
　　●这些任务执行起来容易吗?
　　●执行上述任一操作后对性能有什么提升?
　　●如果当前的配置成倍增长，那么性能也会成倍增长吗?
　　●升级到所需的数量/容量时有哪些体系结构选可以选择?
　　●我需要对用户接口前端做哪些更改才能接纳这些不同的选择?这些更改有多复杂，需要什么技术?更改的成本是多少?最后一点，同时也是最重要的一点，这类要求在开发和部署方面有哪些需要注意的事项?
　　虽然所有供应商都声称自己提供的是“具有巨大升级空间”的技术，但最重要的还是您要调查高容量升级所引发的直接、间接及隐藏成本。

　　总体拥有成本
　　总体拥有成本(Total Cost of Ownership)是您做决策时必须正面解决的一个先决题目。当所有过程都结束之后，您不能只因为技术本身的优势就加以部署。部署的解决方案创建出来的价值应该超过它的成本。目前的问题是许多成本和优势都是无形的，因此难于量化或者难于测量。不过，在对评估的各个产品进行TCO审查时，一定要将数量和估计值包括在内。
　　总之，使用结构化的决策方法应包括上述五个关键标准。正确的方法应确保所有五大要素都得到了评估，从而使决策过程得到优化。在这五大要素中，每一项都应根据其与项目、产品和组织的关系进行利害权衡。