在 XML 数据库发展的早期，在所谓的原生 XML 数据库（NXD）和支持 XML 的常规关系数据库管理系统（RDBMS）之间存在很大的差异。NXD 针对存储 XML 文档做了优化，而老式的 RDBMS 只对可能包含 XML 的常规二进制大对象（BLOB）增加了一些语法改进。

　　现在，NXD 仍然是 NXD，但是更先进了。与此同时，成熟 RDBMS 的供应商努力改进了 XML 文档的存储方法。XML 片段不再被存储到 BLOB 中，而是存储在树结构中。典型的 XML 文档的基本性质就是采用树结构，所以这一改进大大提高了 RDBMS 处理 XML 文档的能力。

　　从早期实现到现在的成熟解决方案之间的这段时间里，在 XML 文档的查询语言标准化方面有了一些重要的进展 —— 其中最重要的是 XQuery 1.0 和 XML Path Language (XPath) 2.0。XQuery 的概念经过了多年开发；最终结果与早期版本有相似之处，但是更加成熟。与 Structured Query Language (SQL) 一样，XQuery 也重视促进供应商独立性和重用。

　　为什么需要 XML 数据库？

　　常规数据库可以存储高度结构化的数据和非结构化数据。这两种数据都需要使用不会频繁变化的数据结构。但是，关系数据库的弱势在于存储半结构化文档方面。与结构化数据不同，这些文档在文档元素的次序和元素相互嵌套的方式方面有很大的自由度。与非结构化数据不同，可以使用描述性标签对元素进行分类。这些元素往往是细粒度的。

　　能够在关系结构中存储半结构化数据吗？当然可以，但是最终很可能形成频繁变化的特殊数据结构，因为一般化的数据结构会丧失标签的描述性；或者使用内容管理系统使用的那种抽象模型，但是这会把数据与元数据混在一起。

　　另一方面，XML 格式非常适合描述半结构化数据。另外，可以轻松地维护数据模型。添加新的元素名并不会改变数据结构 —— 它总是树结构。只需修改 XML 模式，XML 模式描述在树结构中使用和关联元素名的方式。

　　对于工作履历、产品说明和客户订单等文档，XML 可能是最合适的格式。同时，XML 也能够描述结构化和非结构化数据。

　　那么，还需要关系数据库吗？

　　在创建新的软件解决方案时，答案可能是 “不需要”。如果您有一个能够存储半结构化数据的解决方案，那么也能用它存储结构化和非结构化数据。用一个存储解决方案存储所有数据，就能够方便地连接和查询所有数据，这比集成多个存储源中的数据容易得多。

　　但是准确地说，如果要对这个问题回答 “不需要”，那么您的大多数数据应该是半结构化的文档。但是，如果大多数数据更适合采用高度结构化的实体-关系模型，数据不太像文档并且关系更复杂，那么选择 NXD 可能并不合适。

　　那么，如何判断数据的性质呢？另外，如果结构化、半结构化和非结构化数据的数量大体相当，那么怎么办呢？对于这些不确定的情况，好消息是当今的传统数据库已经能够很好地处理 XML 文档或 XML 文档的片段了。在不同的数据库中，访问这些 XML 片段的方式可能有所差异。但是，它们有一点是相同的：它们都使用 XQuery 1.0 规定的构造。

　　解决方案

　　市场上的一些产品以不同的方式实现 XML 数据库，包括 Xindice、Tamino、X-Hive、Oracle 和 Microsoft® SQL Server。但是，我不打算在本文中讨论这些产品。完整全面地比较所有产品是不可能的；另外，本文发表在 IBM 的网站上，而 IBM 是提供 XML 数据库解决方案的厂商之一，因此在此对各种产品发表评论也不容易获得您的信任。虽然我是一名独立的作家，但并不能保证中立性问题。

　　我能做的是讨论具备 pureXML 特性的 IBM DB2 Express-C 并与典型的 NXD 做比较。我选择开放源码项目 eXist-DB 作为 NXD 的代表。eXist 和 DB2 Express-C 都是免费的，都提供了大量用户友好的功能。