SQL Server、Oracle纵横谈

作为现今主流商业数据库产品，SQL Server、
Oracle孰优孰劣的争论历来就没有休止过，从企业级应用的门槛、运行效率、扩展性、高可靠性、运行安全性到总体成本、易用性等等，两个产品间的每一个特性几乎无一不是讨论的话题和争论的焦点。数据库作为运行环境的中心，在解决方案中常常处于比较中心的位置。因此，为了突现己方的方案优势，双方阵营的讨论又常常不仅仅限于数据库产品本身，每每总要和使用的操作系统环境、开发技术（尤其是开发语言）综合而论。
在笔者参与的几个项目中，由于政策和发展远景的考虑，需要同时使用多个数据库产品进行集成，除了即将退出历史舞台的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和新加入的ADO.NET、Native Client支持；Oracle有JDBC、ODBC、OLE DB、OCI的支持，并且提供了.NET版的Oracle Client Provider。在数据容器上，ADO.NET提供了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的项目
下图是这种规模系统的典型部署层次，其中有一个虚的节点表示可能的双机互备、Stand Alone、Read-only DB。
相信在这个规模下，SQL Server 2000、SQL Server 2005、Oracle 9i、Oracle 10g企业版不是您的理想选择。即使您的应用逻辑非常简单，所有的数据访问层逻辑也仅仅使用JDBC或ADO.NET的标准库（或仅作连接的简单封装），笔者也建议您考虑如下的两个集成：

集成一
“SQL Server 2000 MSDE + SQL Server Client+VS.NET 2003 (或VS 6、VS 2005 )，”同时为了进一步节约成本、提高底层的软件质量，您最好集成MS DAAB （MS Data Access Application Block）。
之所以选择DAAB而不是更为全面的Enterprise Library，是因为本集成项目中数据库仅采用SQL Server 2000 MSDE，而不包括Oracle、DB2。所以，选择一个简洁高效的DAAB，既可以省去自行封装数据访问层的开发工作，而且还可以大大减少设计、开发人员学习Enterprise Library中DB部分的“Factory+Object Builder”实现模式的成本。
◆ 从成本角度讲，该集成上线时仅需要支付MSDE的使用许可和一个SQL Server Client（用于管理和维护）的费用。
◆ 从功能角度讲，除了“SQL-92+T-SQL”、存储过程、触发器、物化或非物化视图、临时表外，您还可以使用复制、链接服务器、DTS、SQL Job、AD集成认证、并行查询、DTC服务等功能，结合VS 2003的各种设计器和公共代码块，相信完全可以满足您在一个分布式异构数据源的环境中搭建一个透明的数据访问层。
◆ 从性能角度讲，单个节点对于一个具有200个Online OLTP用户、单票交易数据量在20K Byte以下、90%以上单票交易表关联少于四个表的系统而言，通过该合理的配置完全可以承载。
◆ 如果您的Online OLTP用户数目少于40，笔者建议您完全可以评估采用单CPU的PC机加装Windows 2000 Pro或Windows XP Pro即可，而不用使用Windows 2000 Server或Windows 2003 Server。

集成二
“Oracle 9i标准版+Eclipse（或JBuilder、JDeveloper）”。另外，同样为了简化开发的时间和成本，最好增加Hibernate——原因类似集成一。
◆ 从成本角度讲，把该集成上线，需要支付的是Oracle标准版的费用。
◆ 从功能角度讲，除了“SQL-92+PL/SQL”、存储过程、触发器、物化或非物化视图、DBMS_* 处理包、同义词外，您还可以通过复制、DBMS_JOB、SQL*Loader、RMAN、IMP/EXP等工具满足您大部分开发需要。另外，根据经验，笔者建议您结合DBMS_JOB简单扩展Hibernate来完成具有Schedule功能的数据访问块，这样可以使您的系统既可以同步也可以异步、既可以单票也可以批方式进行处理。
◆ 对于运行平台，本方案有更多的选择：包括Linux、FreeBSD、主流的Unix、Windows NT均可。除去代码编写问题，特定运行环境下的总体吞吐效率，很大程度上决定于硬件、存储和Oracle管理员的个人能力和经验。

其他说明
要在这样低投入的系统上，单个节点达到这样的吞吐量规模，您必须在应用构架和开发中注意如下几个方面：
◆ 充分使用JDBC、COM+或SQL Server的共享连接，尽可能晚用早释放。
◆ 适度、适量的使用存储过程，严格控制各类Constraint的使用。
◆ 计划好批操作和OLTP操作的时间段。
◆ 考虑通过复制、Job这些系统内置的特性来简化应用逻辑和部署。
◆ 充分考虑在这种规模的项目中的备份恢复部分的成本。
◆ 跨库的分布式交易性需要借助COM+和EJB完成。
◆ SQL Server 2005 Express和Oracle 10g XE技术上是更为先进的方案，通过嵌入VS 2005的Integration Service项目和JDeveloper的Oracle 10g Workflow BPEL项目，可以同时协调各种服务，并快速包装成为Web Service完成异构平台间的交互。

1M～10M的项目
这个级别的项目覆盖了当今主要的功能性项目的范围，涉及的内容从OLTP扩展到了OLAP、小规模的DM、全系统或行业的OA、功能较为全面的电子商务站点、遗留系统的整合、小规模的物流、普通规模的ERP或CRM……在这种规模下，两个产品需要从简单的DBMS进一步提升为数据交换的平台、历史记录分析的平台、分布式计算的平台；部署环境也从单一的一个数据中心扩展为“多点数据+1～2个（甚至有可能更多）中心”的环境；从存储上讲，一般也需要引入RAID配合磁盘、磁带，根据数据信息内容，设计小规模的HA和分级备份策略；对于EAI或B2B的数据交换项目，为了保证数据的次序性，还常常需要引入队列，在不同数据库节点间交换数据；在业务处理上，一般或多或少地要将硬编码实现的流转扩展为单独的工作流引擎来总体调度，工作流的过程数据也最好开辟单独的、面向频繁短交易的专用数据库。一般而言这类系统的数据部分运行环境如下：
在这个环境下，笔者建议您在架构设计上应该考虑数据提供商的无关性，除非您的系统仅仅为特定用户的特定运行环境设计，否则为了保证您这种规模方案的通用性，您需要完成一个与数据库厂商无关的数据访问层。在这个层次上，您除了要包括查询、SP、Trigger、DML外，还需要最少提供如下机制：
◆ 数据的缓冲，主要用来保存常用的业务和技术参数、XSD（或其他Schema信息）、XSLT（或其他数据Mapping信息）、表达式解析结果、系统配置信息等。
◆ 可调用的Job控制。
◆ 同时支持同步或异步处理的各类Brokder。
◆ 根据产品特点，还要考虑把工作流的Orchestration作为选件补充到这个数据层中。
◆ 如果在.NET平台开发，为了节省开发时间，保证数据访问层代码质量，笔者建议您集成完整Enterprise Library。
产品选择上推荐采用较新的SQL Server 2005 Enterprise和Oracle 10g Enterprise，结合特定节点的SQL Server 2005 Express和Oracle 10g XE完成。之所以推荐选择较新的产品，主要是考虑这类系统的生命期相对会较长，出于技术升级的原因，笔者建议选择新的产品；另一方面出于成本的考虑，笔者建议采用”企业版+免费版本”方法，将非OLTP、OLAP和DM的其他数据功能交由分散在廉价服务器上的免费版本完成，其一可以大大降低主节点的负载，充分利用各点的计算能力，其二可以将系统的运行风险分担到不同节点，其三可以通过将主服务器配置降低一个层次而在整体上节省成本。
由于这种规模的业务项目一般都分为总部、分支机构和业务现场三个层次。按照一般惯例，分支机构都有一定的特定业务内容，无论是执法尺度、业务流程惯例、特殊现场的特殊技术需要、区域性利好政策等。因此，在主要业务数据集中的前提下，体现特点的业务参数信息和技术控制常常各有各的不同，笔者谈及时常常将这些定制内容称为“地方粮票”。对于这些数据，如果种类和数量不大、更新不甚频繁、网络延时可以满足处理要求，则完全可以集中在一个数据中心，但如果数据种类非常繁多、更新频繁，且包括基于表达式或表达式组的批量规则控制，则最好在设计上将这些“地方粮票”剥离到各个分支处理。
◆ 对于分支数据中混合总部数据和“地方粮票”数据的情况，则可以通过SQL Server或Oracle的单向“推”方式的复制，完成总部数据库向分支数据库同步数据的需要。
◆ 如果涉及两个（甚至更多）中心，则需要通过双向复制，逻辑上向应用层提供单一透明的数据库节点。如果需要同城或异地实时备份，则通过运行机向备份机单向“推”方式复制即可。
◆ 如果为了从时间上减少对白天运行系统的负载，则可以通过Integration Service或Oracle的Import/Export，完成晚间的批量数据的备份和同步。
下页图3是笔者在这种级别项目中常常使用的一个分层部署构架模式，其中的数据库产品已经更新为SQL Server 2005和Oracle 10g系列。

其他说明
根据笔者经验，这种级别的项目中，通过使用数据源无关的.NET DataSet和Java中的ResultSet可以较为容易的构建出来一个数据库厂商无关的数据访问层，这将会开阔您进行选型的范围。在这种环境下开发人员要更多的关注分布式交易的控制、DBA要更多的关注不同数据对象的交易隔离度控制，通过合适的交易模型在完成同样的业务逻辑时可以为这类系统提供更高的并发性和恰当的一致性。

50M～2B+的项目
在展开项目之前，笔者先简单介绍一下这类系统数据上的几个特点：
◆ 这种级别的项目基本上是全行业性的核心业务系统，而且很多是“金”系列项目。
◆ 总要面临到遗留系统的整合、过渡甚至并行运行。
◆ 主机、小型机、PC服务器众多，一般在200+以上。
◆ 操作系统环境众多，包含各类Unix、Linux、Windows NT、Windows桌面操作系统。另外，还有可能面临诸如VMS的旧有系统。
◆ 除了OLTP和OLAP之外，需要以风险管理为目的，提供较为完整地DM支持。
◆ 内部的EAI和外部的B2B要求千头万绪。
◆ 人员类别繁多、开发平台种类繁多。
◆ 受到政策性和远景规划的影响，数据厂商的无关性要求明确。
由于这类项目的内容纷繁复杂，因此笔者仅仅试图从集成的角度进行介绍。根据笔者参与的一个1B+项目经验来看，这类系统除了上一个级别提到的数据访问部分的功能外，架构上必须包括如下几个部分：
◆ 一个实时的数据交换平台，这个交换平台既要为内部新、老系统提供数据交换，更要完成与多个合作伙伴间进行业务上的数据交换。
◆ 一个基于“出版——协调——预订”结构的数据分发平台，由于行业内部还常常包括其他很多周边的项目，常常需要以骨干业务系统为数据源提取处理信息，为了减少这类系统对骨干业务系统的影响，最好采取“一次提取，多点分发”的方式将这些预定的信息异步的分发到其他系统。
◆ 一个全面的运行监控和管理平台。
几者之间的关系如下：
由于SQL Server 2005内置对CLR的支持，因此各类数据对象本身已经支持了面向对象的开发。对于Oracle 10g，也支持J2EE通过面向对象方法访问各种组成。但是，要构成一各提供商无关的数据访问库，则存在一些问题——虽然Oracle 10g提供了面向.NET Framework的设计器和开发库，但SQL Server 2005并没有向Java开发者提供丰富的开发库，因此，如果想设计一个Java版的公共数据访问库，则只能拘泥于SQL调用，而不能真正包装出一个面向数据对象的访问库。
由于SQL Server 2005的Integration Service和Oracle BEPL凭借开发工具的支持都可以很简便地将数据处理包装为Web Service，因此对于系统边界部分的交换，可以通过统一的Web Service方式和遗留系统、其它周边系统、合作伙伴的各类系统进行互联互通，尽量减少系统间的耦合。

小结
由于发展到了SQL Server 2005和Oracle 10g后，两个产品已经远远超出了DBMS的范围，因此，笔者只是“风抚水面式”的对几个规模的集成进行分析和介绍。介绍内容上偏重于布局和功能分割，对于性能、安全性、扩展性内容并未展开讨论，不过如果您选定了某个产品后，性能、安全性、扩展性……内容参考在SQL Server Books Online和Oracle Online Documentation上惠有所介绍。

本文已经发表在《程序员》杂志2006年1月上，转载请注明出处。