如果你可以只做一件事就能改善与客户和业务伙伴的集成关系并提高业务流程的自动化程度，那么这件事一定是实现XML，它已经成为不同系统之间交换信息的标准。XML可以很容易地把信息从一种格式转换为任何其他格式，几乎不费吹灰之力，同样的文件就可以发送给几个不同的客户并满足他们各自特定的需求。不过，要实现这一目标，离不开XML数据库的支持。现实的情况是，很多用户都已经在使用某个关系数据库了，因此他们很想了解这些关系数据库对XML的支持究竟如何？为此，《InfoWorld》评测实验室对目前最主流的四种关系数据库进行了细致的测试，结果表明：Oracle数据库对XML的支持最好，IBM DB2和Sybase ASE紧随其后，而Microsoft SQL Server 2000还有待改进。

合并、查询、转换和传输关系数据库中的数据已经成为商业企业的基本需求。对用户来说,好消息是四种最流行的数据库系统——Oracle Database、IBM DB2、Sybase ASE (Adaptive Server Enterprise)和Microsoft SQL Server不仅能存储XML数据，而且还将处理XML数据的复杂性隐藏起来，让你能轻松地调用这些功能。

然而，这四种关系数据库对XML的支持也不尽相同，有的能提供非常丰富的XML处理功能，而有些却只能提供有限的XML处理能力。

一个时髦的XML数据库应该提供哪些功能呢？归纳起来应该有四个基本功能：使用、存储、查询和产生XML的能力。一个数据库对这四个方面支持的好坏程度实际上反映了它对XML支持的好坏程度。我们分别在Oracle Database 10g、IBM DB2 Universal Database V8.1、 Sybase ASE 12.5.1和 Microsoft SQL Server 2000中对这四个方面进行了测试，测试的内容包括它们如何输入和读取XML文件、存储XML数据的能力、索引和查询能力以及创建XML数据的能力。然后我们依据易用性、灵活性以及它们执行最常见的XML操作的速度来对它们评分。需要注意的是，这些数据库不仅能够处理XML数据，而且还提供了许多其他功能，因此，这里的评分并不代表对这些数据库的全面评价。

三种存储方式

关系数据库和XML文档都是表示数据之间关系的有力工具，但它们的长处却各不相同。例如，在一个关系数据库中查询某个病人的ID将使你能够快速找到该病人来医院看病的日期、当时的症状以及治疗情况，但是，如果你想了解哪一种治疗对应着哪一种症状或者是进行了几次治疗，关系数据库就显得无能为力了。不过，如果同样的信息是用XML文档来记录的，那么你就能轻而易举地获得上述信息及其他一些关系数据库无法提供的有用信息。

不过，是否能结合关系型数据和XML数据的优势取决于你如何存储XML数据。在关系数据库中物理地存储XML数据有三种方法：碎片式（shredded）、结构化和非结构化。碎片式和非结构化存储虽然很有用，但还存在一定的局限性，而结构化方法允许你充分利用关系数据和XML层次结构的能力。

碎片法把XML数据存成关系数据库中的列，但却丢掉了原始XML文档中数据之间的层次关系，如果你不需要继续保持数据的XML格式，那么碎片法就是非常有用的。让我们来看一个简单的例子，假设你有一个Web网站并允许客户在该网站上下订单，如果这些订单需要传送给多个数据库系统，那么创建一个XML文件并让这些数据库系统从该文件中获得数据——也就是说将XML文件打碎——是一种最有效和出错概率最小的方法，因为每个数据库系统获得的数据都来自网络上的同一个共享文件。

非结构化方法利用CLOB（Character Large Object）数据类型，将整个XML文档当做一条单一的记录存储。多年来，数据库一直采用这种方法存储不同类型的文档，因此这种方法并不是什么新东西。虽然非结构化方法仅提供了有限的搜索能力，但它仍然是相当有用的，因为尽管你不能以它为基础进行查询，但原始数据的结构被保留下来了。非结构化XML存储的一大用途是保留原始文档以符合政府的规章。例如，如果一家金融机构收到了XML格式的原始贷款文档，它就可以从中获得每份贷款申请之间的关系并予以记录，而原始申请也保存在该记录中。

结构化方法允许你把XML数据存储在数据库中并保留数据的层次结构，因此，结构化存储也被称为“native XML(本地XML)”存储，这也是每一家数据库厂商希望其产品达到的目标。保留XML数据层次关系带来的最大好处是可以接收XML文档，在关系数据库中组合或修改它，并生成新的XML数据，不过，仅靠关系查询语言是无法实现这一目标的。

在我们所测试的四种数据库中，只有Microsoft SQL Server 2000不支持结构化的XML存储，但所有四种数据库都支持碎片式和非结构化XML存储，不过它们各自所采用的方法和所提供的灵活性却大不相同。

Oracle拔“头筹”

Oracle Database 10g开辟了支持XML技术的新纪元，在输入、存储、查询和产生XML数据方面提供了非常丰富的功能。由于Oracle Database 10g不仅支持非结构化文档存储和碎片式存储，而且还提供了本地的（native）、结构化的XML存储，因此它允许你从文件中获取XML数据并且把它与关系数据进行合并。不过需要提醒你的是，这些增强的XML功能大部分已经在Oracle Database 9i中提供了，因此如果你升级的目的仅仅是为了获得这些增强的XML功能，那么你应该好好考虑是否值得花这笔钱。

Oracle数据库可以从WebDAV（Web Distributed Authoring and Versioning）知识库中读取数据，也可以将数据写入其中，因此它给用户提供了一个非常好的查看XML数据的Web文件夹视图。这种对WebDAV的支持允许管理员不需要占用太多的磁盘空间就能为成千上万的XML文件建立访问链接，因为这些WebDAV文件虽然看起来是普通的XML文件，但实际上它们只是一些快捷符（shortcut）,对它们的查询实际上又回到了数据库中。如果不打开这些文件或者将它拷贝到另一处，那么组成这些文件的数据并没有实际保存在该文件中。利用WebDAV，Oracle数据库可以通过FTP和HTTP来传输XML文档。

或许Oracle Database 10g最重要的改进是增加了对XML schema(XML句法)转换的支持，它允许你通过将现有的数据映射为新的schema来实现XML schema转换。你只需要创建XSLT（XSL Transformation）样式单，就可以把老文档转换成新的schema，而不必把所有XML数据输出后再重新输入进去，其他事情将由数据库自动完成。Oracle Database 10g的XML schema转换功能极大地简化了XML数据的管理，因为管理员经常要面对的事情就是不断变化的需求。

Oracle Database 10g提供了很多方便的途径来存储XML数据。XMLType数据类型屏蔽了存储和查询XML数据的复杂性，允许管理员利用熟悉的SQL工具和概念来修改XML数据。例如，你可以创建一个XMLType表或者在一张关系表中创建一个XMLType列。通过创建XMLType表，你就能实现XML数据的结构化存储并保留其层次结构；创建XMLType列则能实现非结构化存储，这种方法非常适合于把整个XML文档作为关系数据库记录的附件保留。

在视图中能做的事在表中都能做。你可以在存储过程中使用这些表和视图，并在此基础上处理数据，这样一来，你就能够获得极强的处理能力。

在Oracle Database 10g中管理XML数据究竟有多方便呢？如果你完全了解有关XML的一切，包括SQL/XML、XQuery和DTD（Document Type Definition，文档类型定义），那么Oracle数据库中的XML流程就非常容易管理。事实上，就像在schema转换中一样，数据库会自动处理大部分数据管理流程，并使管理员的干涉最少。

在速度测试中，Oracle Database 10g表现极为出色，这些测试包括输入数千个文件、创建数千个文件和输入超大文档。在文档输入方面，Database 10g遥遥领先于其他竞争者，而在文件创建测试中，Database 10g与IBM DB2的性能接近。

“蓝色巨人”排第二

IBM的产品也不错，DB2利用XML Extender选件来处理XML数据，除此之外，需要单独获得许可的Information Integrator也可以处理XML数据。虽然XML Extender听起来像是一个独立于DB2但与DB2的关系引擎进行交互的程序，但实际上它是DB2中一组提供XML功能的存储过程和功能的总称。这些存储过程和功能包含在关系引擎内，就像数据库中的其他任何对象一样，任何需要它们的用户都可以随时访问。惟一麻烦的事情是要使用Information Integrator的功能就必须单独安装它。

Information Integrator不包含在关系引擎中，它通过增加XML Wrapper来扩展DB2的XML处理能力，XML Wrapper允许你把XML文档当做关系源来处理。当你希望接收某些XML文件以便进行查询和报告，但却并不想把它们输入数据库中时，XML Wrapper就是一个非常强有力的工具。

与Oracle数据库一样，DB2允许你存储结构化的XML、非结构化的文档以及碎片数据。也像Oracle的XMLType一样，DB2的XML数据类型屏蔽了XML数据存储的细节，你可以创建一个视图将关系数据和XML数据合并到一个单一的结果集中，这个结果集又可以在文件系统中与XML文档合并，或者与数据库中的其他XML数据或关系数据合并。

在DB2中，当你从关系数据创建XML文档时，SQL/XML是主要的查询语言，你可以用SQL/XML功能创建XML标签、属性等，同时还允许你在创建文档的同时完成串联和聚合。虽然DB2的SQL/XML支持还不完善，但它已经提供主要的功能。今天，当你在用DB2创建XML文档时，你基本上能做你想做的任何事情。

不过遗憾的是，DB2完全不支持XQuery。毫无疑问，IBM是在等待W3C宣布最终的规范，然而，缺少了对XQuery的支持，DB2的XML搜索能力就大打折扣了。其实，哪怕是部分实现标准也比等到标准公布后再完全实现要好。

XQuery是一种通过结构化数据的路径来进行搜索的语言，它所提供的查询功能比SQL能提供的强很多。因为XQuery是基于标识（identity-based）的查询语言，而SQL是基于值（value-based）的。你可以用XQuery查询是否有某个元素存在；而SQL可以告诉你某个已有元素是否包含了特定的值。与SQL不同，XQuery还能查询元素标签中的属性，并且有比SQL更强的数据类型，因此，XQuery为数据类型的写入和查询提供了更强的控制能力。

尽管不支持XQuery，但IBM对XML的承诺和支持还是非常明显的，你只要看一看IBM在DB2 V8.1中所做的改进就会明白这一点。DB2 8.1不仅支持XSLT以实现XML数据的动态转换，而且还对SQL句法进行了1000多种修改以便于单独处理XML数据。

在DB2中管理XML数据有多容易呢？非常容易！视图负责管理动态数据并提供了一个抽象层以方便客户有效地查询数据库。然而在DB2中更新XML schema就有点困难了，因为它不支持schema转换，你必须物理地将老数据重新映射到因需求变化而改变的新schema中。

DB2的开发界面非常直观，比Oracle甚至比Sybase的都要强很多。此外，尽管不支持XQuery，但DB2的确提供了非常强的XML能力，在测试中，我要求它做的每一件事情，它都做得又快又好。

Sybase紧跟随

Sybase在Sybase ASE中实现XML的方式很受用户欢迎：本地的XML支持完全集成在关系数据库中，不需要任何外部程序的支持。

Sybase ASE包括一个本地的XML数据库，支持碎片式、结构化和非结构化XML数据的存储。数据库管理员可以向数据库输入XML数据，也可以直接在文件系统中查询XML文件。不过遗憾的是，ASE也不支持XQuery，因此在搜索XML时ASE的局限与DB2一样。

与Oracle和DB2一样，ASE允许对各种XML数据进行非常丰富的索引,无论是碎片式还是结构化的都是如此。ASE中的自定义索引机制负责处理各种XML格式，不需要任何用户输入。元素值被自动索引以加快断言搜索速度（例如，XML等于“从lastname=smith的客户中选择电话号码”），数据库也会根据查询断言的类型来选择不同的索引类型（XML索引或关系索引）。除此之外，查询既可以利用关系元素也可以利用XML元素或者同时利用二者来完成。

ASE替你完成大部分XML数据管理工作。建立视图、存储过程以及基于XML数据的功能不仅容易编码，而且便于管理。

然而，缺乏schema转换功能会影响项目的扩展。实际上，缺少schema转换功能并不是ASE惟一的不足，当你创建XML文件时，ASE无法同时完成XSLT转换，因此终端用户必须先创建XML文件，然后通过XSLT处理器来运行它们。如果你需要经常创建XML文件，你就应该选择其他解决方案，Microsoft .Net就非常适合完成这项任务。

如果不是缺乏XSLT和XQuery支持，ASE的XML处理能力就会与IBM甚至Oracle并驾齐驱。Sybase ASE最值得赞赏的有两点：开发非常容易，且工具很直观，因此对那些目前正在使用ASE的公司来说，ASE是一个值得继续采用的好产品。

在进行速度测试时，ASE表现尚可，但在创建XML文件时速度稍慢，当需要编写XSLT脚本时，ASE的性能也受到影响。如果ASE提供对XSLT的支持，那么它的性能将会与其他产品的性能一样好。

微软尚需努力

在处理XML方面，Microsoft SQL Server 2000明显落后于Oracle、IBM和Sybase。作为一个XML-enabled数据库，SQL Server仅允许你以非结构化对象的形式存储XML文档，或者是把XML数据打碎存储在一张关系表中。

你或许会认为缺乏对结构化XML的支持会使SQL Server陷入水深火热之中，但事实并非完全如此。SQL Server提供了非常丰富的功能来支持解析和编写XML文档。首先，你可以在SQL Server中利用T-SQL查询中的For XML句型很容易地产生XML结果集。这一功能本身就很有用，而如果与通过XSLT式样单清洗数据的能力结合起来，就更有用了。

SQL Server还提供了其他更丰富的选项帮助你创建XML文档，并允许你分割视图，以用户所要求的任何形式展示XML数据。你也可以把SQL Server当做一个双向的XML知识库，利用Updategrams功能将XML文档直接映射到关系表中，这一功能使你能以XML文档的形式更新、插入和删除SQL Server中的数据，其结果仍然是XML数据。

在读取XML文档时，SQL Server所提供的功能更强。例如，SQL Server可以把XML文档作为参数传递给存储过程，并将它分解后存储在数据库里。此外，SQL Server的OpenXML功能允许你从XML文档产生行集（rowset），并将它们插入关系数据库中。事实上，利用OpenXML，你可以采用一些很好的方法来修改XML数据，你可以利用标记获得属性和元素，你也可以利用列模式或表名称来定义行集schema。

然而，由于SQL Server把整个XML文档当做一个单一的数据块处理，因此在你开始在存储过程中解析它们之前，数据库并不知道有XML数据存在。但这并非世界末日！你仍然可以查询和查看XML文件中数据之间的层次关系，只不过要多花些力气罢了！预计在2005年发布的SQL Server下一版本将支持结构化的XML存储。

SQL Server是否能满足一个XML项目的需求取决于你打算做什么？如果你仅仅想把一些XML文档输入你的关系数据库，并愿意损失掉XML数据的结构信息，那么SQL Server能很好地满足你的需求。不过，在这种情况下，.Net或许更合适，因为.Net工具可以更简单地处理某些事情，包括创建XML文件。

在我们的测试中，SQL Server输入XML文件的速度很快，但创建XML文件的速度最慢，而且它读取大型XML文件的速度也最慢。

结 论

我们所测试的四个关系数据库都提供了有用的XML能力，即使是不支持结构化XML存储的SQL Server也允许你存储、修改和创建XML。

不过，与Oracle相比，微软、IBM和Syabse还有很多事情要做。IBM DB2和Sybase ASE还存在一些明显的局限：缺乏对XQuery的支持意味着粒状的XML搜索能力不够。Sybase ASE不支持XSLT即兴转换，这使得产生XML文档或完成Schema变换需要花更多的时间。而Oracle不仅非常成功地隐藏了管理XML数据的复杂性，而且还提供了丰富的查询能力和其他功能，包括支持Schema变换和WebDAV仓库。

·趋势·

XML数据库的未来

随着大多数主流的关系数据库引擎对SQL和XML的支持能力逐渐融合在一起，你或许会就此得出结论：专用的XML数据库没有前途了。但事实并非如此，一年前，BEA公司首席架构师Adam Bosworth在InforWorld CTO论坛上的主题演讲中解释了专用的XML数据库为什么仍然很有价值，并且指出了它们的新使命。他说:“在我们正在建设的面向服务架构中，粗粒度的XML消息是‘纲’，纲举目张！我们将产生大量的粗粒度的XML消息，而面向服务的处理器不仅仅是转发这些消息，它们还要扫描SOAP头信息、关联消息、增强安全策略，并且对XPath风格的查询给予响应。所有这些都需要在一个不能容忍任何延时的实时环境中完成。”

Oracle Database、IBM DB2、Sysbase ASE和Microsoft SQL Server已经建立了一套完整的处理方法来满足一系列不同的需求：读写多用户访问的事务数据，这些数据具有良好的关系结构。而消息代理则不同，它负责处理“瞬时”消息，这些消息并不是由很多并发用户来写的，它们大部分也不符合ACID（原子的、一致的、持久的和孤立的）事务模型，此外，它们也不具备很好的关系结构。当然，你可以用一个能够处理XML数据的关系型引擎来充当XML处理器的核心，不过这就像是开着“悍马”车去上班（“悍马”是一种庞大、沉重、昂贵的高级越野车，可在非常恶劣的环境下行驶，不过它可不是用来上班的代步工具！）

如果你已经购买了SQL/XML“悍马”，那你就没有理由不充分利用这项投资。你真的还需要去买一辆XML跑车吗？回答很可能是“不需要！”。你可能需要购买的只是一个企业服务总线（诸如Sonic ESB）或者一个服务架构（诸如webMethods Fabric），它们都会嵌入一个过去曾经是独立产品的XML数据库。例如， Sonic XML Server曾经是一个名为eXcelon的独立产品，但现在已经被包容在Sonic ESB中。

　　Software AG的Tamino是否也会被嵌入到ESB中？虽然该公司的CTO Bill Ruh并没有做出这样的宣布，但他也没有否认这种可能性。“我们非常愿意创建一个基于XML的企业服务总线”，他说，“我们的中间件可以设置XML数据规则、完成消息输入和输出、调用其他应用、等待并基于返回的值做出决定。”

当然，你完全可以用本地XML数据库来管理由新一代支持XML的终端用户应用产生的大量业务文档。例如，搜索保险数据库以查找符合某些结构化元数据要求的事故报告，但混合的SQL/XML数据库不仅能完成这些任务，还可以把结构化的XML内容结合到关系列中——这是一种功能强大的组合，因此本地XML数据库的应用正在转向那些SQL/XML数据库无法覆盖或者不愿意覆盖的小领域，它们将成为新兴的服务Web中的XML“助推器”。（陈敏编译）

·预测·

Yukon会赢得XML之战吗？

预计在2005年中期交付的Yukon将是微软在XML竞技场上亮出的新武器。为了与IBM、Oracle和Sybase的关系数据库提供的本地XML存储能力相抗争，Yukon将在保留Microsoft SQL Server 2000已经具备的碎片式和非结构化XML存储能力的基础上，提供结构化XML数据存储能力。

Yukon保留XML文档中层次化数据关系的方法与IBM、Oracle和Syabse所采用的不同，它不会采用嵌套表来存储结构化的XML数据，而是采用了可管理的BLOB（Binary Large Object）数据类型。这意味着虽然数据被被映射成常规BLOB数据类型，但XML数据的层次结构仍然被保留下来，不过，这种方法也带来了一个问题：你在Yukon中存储的XML文件大小不能超过2GB。

这种限制对应用有影响吗？有人认为这是一个严重的问题，但我要告诉你：我从来没有看到容量达到1GB的XML文件。事实上，XML是用来在文件中查找某个记录，而不是用来把整个数据库放入一个文件中，然后再对它进行XQuery查询！

本地XML数据存储还不是Yukon在XML数据管理方面的惟一改进，它还提供了Schema转换功能，但它所采用的方法与Oracle不同，你可以通过改变名称空间（namespace）来更新现有文档，而不是像Oracle那样通过粘贴新的Schema并利用XSLT(XSL Transformation)清洗现有数据来完成这一任务。微软的方法不需要验证现有的数据，而Oracle的方法允许你根据新的Schema补上缺少的数据，在这方面，Oracle的实现方法更灵活。

你也可以采用多种方法来验证Schema:你可以直接创建一个XML Schema;在创建表格时附加一个Schema;或者利用映射功能在查询中转换数据类型。依据我使用Yukon测试版本的经验，我发现一旦你启用了Schema验证功能，你就无法关掉它，但这并不是一个坏消息，因为完成Schema验证是非常昂贵的。为了节省时间和计算资源，你不会总是想用Schema验证，特别是对于那些可信任的数据源，这种验证或许完全可以省略。

总之，微软看来已经迈出了正确的一步，但要说Yukon已经成功了还为时过早，但希望总是有的！