作为现今主流商业数据库产品

作为现今主流商业数据库产品，SQL Server、

Oracle孰优孰劣的争论历来就没有休止过，从企业级应用的门槛、运行效率、扩展性、高可靠性、运行安全性到总体成本、易用性等等，两个产品间的每一个特性几乎无一不是讨论的话题和争论的焦点。数据库作为运行环境的中心，在解决方案中常常处于比较中心的位置。因此，为了突现己方的方案优势，双方阵营的讨论又常常不仅仅限于数据库产品本身，每每总要和使用的操作系统环境、开发技术（尤其是开发语言）综合而论。[zt]

[Ref: /article/match_article3.html ]

在笔者参与的几个项目中，由于政策和发展远景的考虑，需要同时使用多个数据库产品进行集成，除了即将退出历史舞台的RDB（运行于VMS系统）外，常常需要同时使用SQL Server 和Oracle，此外还常常会选择SAS、Access等数据产品配合SQL Server、Oracle的使用。通过几年的使用，笔者逐步认识到对数据库的选择标准以恰到好处最佳，即要在恰当的位置使用最合适的产品。本文笔者试图通过版本、运行特性和集成三个方面对两个数据库产品进行简要比较，比较的结果不是目的而是希望对读者的架构设计有所参考和借鉴。

从版本谈起

从微软开始加入企业级开发算起，真正称得上对手的两个组合应该是SQL Server 2000 vs.Oracle 9i和SQL Server 2005 vs.Oracle 10g(2nd)。

SQL Server 2000 vs.Oracle 9i

由于发展战略上的调整，直到SQL Server 2000版本中，微软才为其内置XML的支持，较之Oracle的Oracle 8i提供的对应特性显得有些迟缓。但从技术方案的情况看，基于Internet的XML的处理并没有出现一边倒的情况，主要是微软通过提供各类XML的COM开发库从应用（中间层或客户端）层面提供了对XML的支持，弥补了SQL Server 7和Oracle 8i在这一领域的差距。

SQL Server 2000和Oracle 9i分别对于微软和Oracle都具有非比寻常的战略意义。从微软讲，SQL Server 2000是其进军企业级开发领域的一个基石，通过DTC的协调作用和COM+的粘合作用，保证SQL Server 2000可以和其他主要Windows Server连成一个交易性的整体，为其争夺原属于IBM和Oracle的领域提供了技术上的保证；而Oracle 9i也是Oracle完全突破数据库产品，通过自身优势直接扩展到应用服务器产品线的一个转变。

SQL Server 2005 vs. Oracle 10g(2nd)

随着SQL Server 2005和Oracle 10g的推出，两个产品的竞争从简单的数据库本身的竞争，直接变为两套数据处理模式的竞争。不过依笔者所见，这种竞争的实际冲突的范围正在缩小，这个现象主要来自每个产品扩展功能所依托的开发环境——.NET Framework和J2EE。Oracle 10g的一张大牌就是这个“g”，通过网格将各处的计算资源汇总为一个可计算的整体，然后仅仅通过一个Portal就可以使用所有的资源。Oracle的这个考虑不仅是技术上的，更主要是竞争需要，因为通过网格就可以向Windows NT、IBM AIX，其他Unix和Linux系统提供数据计算服务，直接跨越微软和IBM的技术本体优势。不过，经历六年磨砺的SQL Server 2005似乎更加来势汹汹，在众多组件中笔者最为关注的是“Integration Service+Service Broker”的

组合，因为这是微软通过其客户端优势，将众多数据库、数据仓库厂商产品的抽象和透明封装。

总体特性比较

抛开类似七龙珠中战斗力值一样不断你追我赶的各类测评数据不谈，其实两个产品的总体差别并不大，或者就数据库产品而言没有很明显的泾渭之分。下面是DBMS之外的一些主要特性的比较：

◆作为公认的数据库厂商，Oracle走的是多平台兼容的道路，而SQL Server则深深植根在Widows平台上；Oracle的产品可以运行于各主流操作系统平台，在兼并了RDB后更是提供了对VMS环境的支持，而SQL Server仅仅支持Windows操作系统。

◆大家普遍讨论的并发性、吞吐率问题，其实就是对两个产品交易隔离度、存储的控制问题讨论；至于产品使用中的不同感觉，主要与运行硬件、操作系统平台和DBA的配置（或没有配置，而采用出厂的默认配置）有很大关系。

◆在操作易用性上，Oracle由于有了各类Java GUI的支持，迅速弥补了这一部分与SQL Server 的差距。

不过根据笔者的经验，资深的DBA最经常使用的还是“Console+积累的脚本”对他们而言除了一些新特性外，易用性不能算作问题。

◆在产品的连续性方面，Oracle一脉相承，而SQL Server在SQL Server 2000和SQL Server 2005的两个版本上虽然提供了非常多的升级工具，但在实现上，很多内容都是推倒重写的。

◆在客户端支持方面，SQL Server有ADO、OLE DB、DAO、ODBC和新加入的、Native Client支持；Oracle有JDBC、ODBC、OLE DB、OCI的支持，并且提供了.NET版的Oracle Client Provider。在数据容器上，提供了DataSet，将单个关系扩展为一组关联关系的内存数据库，这虽然对架构上影响不大，但对于应用设计而言却可以提供比Java更多的选择，尤其在级联数据的处理上更加高效。

◆Oracle在9i中已经有相对完善的Java支持，SQL Server直到2005版本中才增加了对CLR 的支持。不过就如业内普遍规律“后来的总是先进的、早来的总是成熟的”一样，此番SQL Server 2005基本上实现了一个“完整版的Hibernate”，不仅仅是存储过程、触发器、视图，而是整个SQL Server 2005环境的对象化支持。

◆国际化、本地化方面双方的支持都非常完备，难分伯仲。

◆对于移动设备而言，双方均有移动设备版的产品，可以嵌入到这些智能设备中使用，但由于面向的设备类型交叉面比较小，所以只能算是各有千秋。

◆对于空间而言，Oracle在10g中提供了一个完整的2-D、3-D数据开发平台，而SQL Server 2005中没有对应的产品。

◆在人类语言识别方面，SQL Server 2005和Oracle 10g基本上并未在这上做更多的扩展。

◆通过增强的Reporting Service和Notification Service，SQL Server 2005与Oracle 10g在报表和通知两个方面平分秋色。

项目集成

相信这个话题将是争议最集中的一个部分，一般的讨论往往从项目的技术类型上展开，例如：企业核心业务系统、数据交接系统、OA、风险管理系统、嵌入和移动项目、空间系统、多媒体信息等。这里笔者仅根据“数据库+ 开发工具+ 数据访问层逻辑开发+ 数据库服务器”五部分的项目费用规模来分别展开介绍，由于项目的复杂程度不同，费用有较大差异，因此笔者的分级并不是连续的。

20K～500K的项目