用于数据的XML：Native-XML 数据库：一个关于数据的坏主意？

用于数据的XML：Native-XML 数据库：一个关于数据的坏主意？

－－关注对于 Native-XML 数据库的支持和反对意见

Kevin Williams （kevin@realworldxml.com）

首席 XML 设计师，Equient（Veridian 的一个部门）

2001 年 10 月

专栏作家 Kevin Williams 从正反两面讨论了使用 Native-XML 数据库存储结构化信息。他概述了使用结构化数据的常见需求，并讨论了 Native-XML 数据库在满足这些需求方面做的如何。

该专栏文章讨论了所谓的 Native-XML 数据库。我经常听到的关于 XML 数据的问题之一是“我们真的需要 Native-XML 数据库吗？”在这篇专栏文章里，我的任务是分析何时把结构化数据存储到这些专门的数据库里是有意义的。

到底什么是 Native-XML 数据库？

毫无特别，Native-XML 数据库是以 XML 格式存储信息的数据库。同样，这些数据库创建一些索引，并将这些索引与 XML 文档一起存到资源库中，以支持快速搜索资源库来查找包特定信息的文档。就在作者写本文的同时，有数家公司在竞争这一市场，其中包括 Ixiasoft（它们的产品是 TextML）、Software AG（Tamino）以及 XYZFind。但是这时还不能抛弃关系数据库！让我们看看这些工具的长处和短处。

结构化数据资源库应该做什么？

当使用结构化数据工作时，（粗略地讲）需要执行四种不同功能：向资源库添加结构化信息、从资源库检索信息、在资源库中搜索信息以及从资源库聚合信息。在这些功能方面，Native-XML 数据库做的怎么样呢？

存储

在资源库中存储信息很简单。如果希望存储的信息已经是 XML 格式，那么可以直接把它添加进资源库。这也许听起来不错。毕竟在不断创新的 Web 服务世界中，将要到来的多数信息将使用嵌入在 SOAP 消息中的 XML 片段格式。然而，把 XML 文档分解并保存到关系数据库一点也不困难；当开始查看希望支持的其它功能时，这种作法会有一些好处。同样许多本 Native-XML 数据库供应商所鼓吹的一个好处是 Native-XML 数据库能够存储和查询异种的文档结构。再说，对于结构化数据问题在于：您真的希望信息的结构千变万化吗？对于使用 XML 文档时具有的这种优势，当使用结构化数据时就算不上是一种优势了。

检索

初看上去，从 Native-XML 数据库检索信息似乎也是一个好处：以信息的原始 XML 格式检索它，而不需任何附加的编码，并且可以使信息以一定的样式显示。然而，结构化数据检索的性质使得这种明显的优势实际上变成了劣势。如果信息更新量巨大（例如，接收单个数兆字节大小 XML 文档的股票系统的夜间更新），一些 Native-XML 平台需要从数据库返回整个文档 — 即使您只对文档的很小一部分感兴趣（譬如某个特定股票的变化过程）。 其它 Native-XML 平台在将 XML 文档保存到资源库之前进行分解，但是如果具有复杂的文档结构（正如许多结构化 XML 文档倾向于具有这种结构）时，这样做就显得有点笨拙。无论如何，许多关系数据库供应商目前正在实现瘦 XML 序列化器包装器以便支持在需要时从关系数据生成 XML 文档。这使得程序员可以容易地获得完成特定任务所恰好需要的信息，这些信息具有某种格式，这种格式具有所需样式、或者可以发送给其它能识别 XML 的目标。

搜索

搜索 Native-XML 数据库有两种常规解决方法可用，选取哪种取决于数据库供应商。一些 Native-XML 数据库需要选择哪些元素或属性用于索引，如同在关系数据库里选择哪些列用于索引。然后，这个信息被用于建立索引，以便搜索机制能用来快速定位相匹配的文档。在文档被添加到资源库时，其它 Native-XML 数据库就是对文档内的所有信息建索引，可以想象这将导致存储空间需求飞速上升（想象一下在关系数据库中对所有列建索引！）。由于这些数据库以文档为中心的性质，搜索将返回一组 XML 文档；然后如有必要，调用程序还得对这些文档做进一步处理。 很遗憾的是，这意味着更复杂的搜索，是很不方便的。例如，要找出那个对某一特定部分提交最高订单的顾客，以为在中间环节要处理很多事情。在指向关系方面 Native-XML 数据库做的也不好。结果是，如果数据结构不是纯粹层次结构的，则对您而言，Native-XML 数据库就不是恰当的解决方案。大多数 Native-XML 数据库具有这一功效强大的特性 — 执行完善的全文搜索的能力，包括整个同义字支持、字根（匹配一个字的所有形式：现在时、过去时和进行时）以及相近搜索（DTD NEAR XML Schema）。此外，在使用传统文档时，这些特性是不可缺少的，其中上下文在含意上起着重要的作用，而当使用结构化数据时，就远没有那么重要了。

聚合

使用关系数据工作时，聚合是所需要的最重要功能之一，事实上它处于联机分析处理的核心（OLAP）。Native-XML 数据库在执行聚合任务方面表现得特别差。因为信息要么被保持在文档这一层，要么一般被分割成节点，所以把信息汇集起来以及集中处理它（求和、平均数等等）就很困难，此外，还必须在中间环节增加附加代码。如果结构化数据应用程序需要任何一种分析处理 — 我打赌它会需要 — Native-XML 数据库将会使您失望。

结束语

该专栏文章对 Native-XML 数据库及其能力评价不高。尽管那些数据库在观念上很适合面向文档信息（非结构化或半结构化的数据）管理，但对于结构化数据的使用，它们没有什么意义。如果需要结构化信息作为 XML 来访问，则利用关系数据库供应商所提供的 XML 支持，这样情况会好一些。