数据库选型的五大要素
面对品种繁多的数据库产品，如何才能独具慧眼，选中适合自己的数据库产品呢？众所周知，正确的评估、选型与数据库技术本身同样重要。而通常，数据库厂商都会在性能清单和技术基准表中尽量展现产品最佳的一面，对产品弱点却避免提及或进行遮掩，关于这一点，业界已经是人尽皆知了。其实在挑选和评估过程中，首要目标是选择一款能够满足甚至超过预定要求的技术或解决方案。选型的正确方法将使用户在面对众多产品时，提高其做出最佳选择的能力。数据库选型时，必须考虑以下五大因素：
1. 开发要求
2. 性能/成本
3. 数据库运行和管理
4. 可升级性
5. 总体拥有成本
开发要求
首先，需要清楚自己究竟想使用什么开发技术。例如，你是要以ADO.NET访问传统的关系型数据库？还是要以纯面向对象技术构建J2EE应用平台？又或是需要建设XML Web Services？如果你要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准（和非标准）SQL功能有多少？
如果你要规划的是面向对象开发策略，那么在原计划里的数据库支持真正的面向对象吗？它是如何支持的？若有需要,它能同时提供SQL的功能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但实际上并不是直接支持的。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。
另外，你还需要确定自己的前端技术如何与后端进行“对话”。你的业务逻辑是放在客户机一端呢？还是放在服务器一端？你要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是快速应用开发（RAD）环境吗？
目前，实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,如果实现的是基于面向对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓后关系数据库。它所代表的正好是关系数据库和面向对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象逻辑操作的平台。它的出现已经为传统数据库领域带来了冲击，而在面向对象数据库方面更是广受欢迎。
性能/成本
测量数据库性能最常见的方法是TPC基准。TPC明确地定义了数据库方案、数据量以及SQL查询。测量的结果是，在特定的操作系统上，配置了特定的数据库版本，以及在惊人的硬件条件下，每项事务的成本是多少——其中的事务可以是TPC测试中定义的任何数据库操作。
从理论上来讲，这类基准旨在提供不同产品间客观的比较值。但在现实中，这些方案又有多少能准确反映并回答你在挑选技术时所存在的疑惑？其次，所有技术厂商发布的TPC基准都会超过以前发布的结果。这样，TPC基准在更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。
以笔者多年所见，只有在真实的环境中进行实际的比较测试才可以推断出数据库的预期性能及评估所需成本。常用的方法包括平衡移植，把原来的数据转移到类似硬件上的另一套数据库，然后以真实的客户端连接这套测试对象。又或是以数据产生器针对真实的数据模型，建立出庞大的数据量，再以客户端连接作测试。
这种做法跟实验室中的做法的不同之处有以下几点：第一，试验中的硬件构架跟你预期的方案不会有太大的差别；第二，所测试的事务在宽度和深度方面跟未来计划的也差不太远；第三，如果是硬件条件一样，我们可以直接看出测试对象跟原来方案有着多少差异。
掌握了以上结论之后，我们应该可以更精明地为所需的性能投入相应的成本。换句话说，我们将能够更准确地预测各种数据库的性能与相应的成本。
数据库运行和管理 所有数据库都需要进行管理。数据库管理涉及以下问题：
· 操作任务：备份、故障切换、灾难恢复，等等；
· 整理系统：分段、存档；
· 访问控制：定义、监控；
· 性能：保持系统在线和优化运行；
· 数据库方案变更：更改数据库结构、更新索引、数据库同步。
有些数据库需要比其他数据库投入更多管理资源，业界通常以一家公司必须雇用的数据库管理员（DBA）人数的多少来做比较，这是因为只有雇用足够数量的管理员才能在确保系统运行平稳的同时，又能维持数据库的完整性。
因此，在数据库选型时应考虑以下问题：
· 产品需要多少数据库管理员？
· 他们负责什么？
· 什么任务需要停机？
· 停机时间会有多长？
· 这些任务的困难/复杂程度有多大？
· 执行这些任务需要什么技术？
· 这些任务如何管理（现场还是远程）？
· 现在有哪些工具可以帮助完成这些任务？
· 所有优化措施都可行/容易执行吗？
过去选择数据库时，因为别无他选，大部分项目经理、信息主任在考虑问题时已经不再看重以上因素，理由是不管选哪一品牌的产品，他们还是要长时间地付出同样昂贵的维护及管理费用。而目前市面上出现的一些新的数据库为行业带来了一定的冲击，除速度和处理能力之外，更重要的是，为信息主任们分担了大部分繁杂的工序，过去一些必然的管理和优化操作，现在全自动完成，已招聘的人力资源可改而投入单位里其他岗位，创造更大的价值。
可升级性
随着对数据库应用软件使用的不断增加，很可能某一时刻当前的硬件配置就不够用了，这时你就需要对硬件进行检查。升级可以朝两个方向发展：垂直升级（使用更大/更多的处理器）和水平升级（使用与当前平台同一规格的更多的计算机/处理器）。 在考虑可升级性时，用户应首先回答以下问题：
· 业务逻辑能和数据分离吗？
· 业务逻辑能拆分吗？
· 数据库能分段吗？
· 这些任务执行起来容易吗？
· 执行上述任一操作后对性能有什么提升？
· 如果当前的配置成倍增长，那么性能也会成倍增长吗？
· 升级到所需的数量/容量时有哪些体系结构可以选择？
· 我需要对用户接口前端做哪些更改才能接纳这些不同的选择？这些更改有多复杂，需要什么技术？更改的成本是多少？
· 最后一点，同时也是最重要的一点，这类要求在开发和部署方面有哪些需要注意的事项？
虽然所有供应商都声称自己提供的是“具有巨大升级空间”的技术，但最重要的还是你要调查高容量升级所引发的直接、间接及隐藏成本。对“服务器群（Server Farms）”一词相关的技术切勿掉以轻心。那些好的数据库所带来的机遇应该基于它所支持的各种主流的操作系统平台，以及研发多年成熟和稳定的网络分布式数据缓冲技术，确保在垂直升级时不用对应用程序做任何修订，更可在不影响日常业务运作的情况下，实时调整服务器群的规模。
总体拥有成本
总体拥有成本(Total Cost of Ownership)是你做决策时必须首先面对的问题。作为一个专业的决策人员，不能只因为单项优势(如软件价格）就加以采纳，所部署的解决方案创建出来的价值理应超过它的成本。
目前的困难在于许多成本和优势都是无形的，因此难以量化并且难以测量。不过，在对评估的各个产品进行TCO审查时，一定要将数量和客观的估计值包括在内。否则不仅对产品的情况掌握得不够完整，还有可能导致结论不够全面，从而产生负面结果。需要考虑的一些成本和优势如表1所示。
表1 数据库选型中的成本和优势
下面我们来举例说明，如果我们需要在数据库A和B之间进行选择。在考虑TCO的前提下，我们应该做如表2所示的计算。
表2 数据库A和B的TCO计算
从表面上看来，数据库A价格便宜、实施的成本也相对地低一些。但要达到预期的服务水平，硬件和维护的成本却要高很多。相反，数据库B售价高昂、实施时的风险高一点所以成本也高很多，但因为它的技术水平比较高，相对的硬件和维护成本就要低很多。结果是，数据库B的方案，长远来讲反而更有利。通过以上的假设，说明如果通过TCO审查，我们能更全面地看到事实的真相。
为什么要用关系型数据库而不用非关系型数据库。
1、对于增删改查操作，关系型数据库和非关系型数据库的性能开销基本一致，因为所有表的数据量都非常小，小于百万级，因为在千万级数据量以下，关系型数据库只要设置了索引，都是非常快的。
2、在性能方面一致的情况下，非关系数据库的缺点在于无法支持动态连接查询应用，即sql中的join操作，或者说是join效率不如关系型数据库高，另外也不支持分组(group)和统计操作(count/sum/avg等)，在业务系统中存在大量的join操作，比如，报表打印、银行缴费对账、员工、机构、角色、交易、科目、字典等复杂应用都涉及到大量关联，所以非关系型数据库在这些处理方面不如关系型数据库灵活和性能高，编写的代码可读性和健壮性也较低。
3、关系型数据库的管理工具，比非关系型数据库的管理工具更丰富，也更完善。对于数据库的DBA维护而言，关系型数据库的批量更新、导入、导出、备份、优化等方式和资料都丰富，对于开发人员的入门门槛，关系型数据库也比较低。
4、关系型数据库的发展历史和稳定性要超过非关系型数据库。
5、既然在性能一致的情况下为什么不用关系型数据库呢。
6、统计和数据分析相关的数据库就必须是用关系型数据库了，因为大量的统计应用都是基于sql中的统计函数的，比如查询交易业务性别比例、学历分布等，都涉及到sql操作，比如，join,group by xxx,sum(),count(),avg()等，这些都是非关系型数据库不支持的。
本文来源：https://www.2haoxitong.net/k/doc/26c2ec2f4028915f814dc2e3.html
文档为doc格式