RSS、Atom、mashup、高级搜索要求和其他发展正使得原生 XML 数据库成为搜索应用程序和服务的一个重要组成部分。XML 数据库类型的优势在于擅长高效地在大量半结构化（semi-structured）的数据中进行搜索。在本文中，您将发现一些用于最大化使用 XQuery 和 XML 数据库的应用程序的性能的一般原则。

XQuery 和原生 XML 数据库

在某些情况下，在原生 XML 数据库系统中使用 XQuery（一种用于查询 XML 数据集合的函数型语言）可能非常有用。与标准关系数据库相比，原生 XML 数据库在服务于主要是只读的复杂查询时能够提供更快的响应时间和开发时间。XQuery 是目前最简单、最强大的数据转换系统，它完美地内置在查询语言中。借助 XQuery，可以实现更快的开发时间，因为无需设计一个单独的全文本索引系统，或者为用户组装大量数据。

以减慢插入和更新速度为代价，原生 XML 数据库能够提供无与伦比的开箱即用响应时间，因为它们保持数据基本上非规格化（denormalized），提供默认索引，并能极好地利用可用 RAM。但是，在处理超大型数据集时，您还可以通过遵循以下一般原则进一步改善原生 XML 数据库的查询响应时间。

1、避免规格化

2、采用唯一的元素名称

3、预先计算值

4、通过查询转换数据

5、剖析 XQuery 代码

6、保留优化列表

这些原则是通用的，适用于当今可用的许多原生 XML 数据库，包括 IBM DB2 Express-C、Mark Logic Server、eXist、甚至 Oracle Berkeley DB XML（参见 参考资料 中的链接）。接下来，我们将详细探讨这些优化原则。

避免规格化

设计原生 XML 数据库模式时，最重要的事情是避免使用设计关系数据库时采用的方法来规格化数据。

原生 XML 数据库的数据规格化过程涉及到设计多个 XML 文档类型，这些文档类型相互链接的方式与关系模型表相互链接的方式类似。但是，在多数情况下，需要尽可能少（如果有的话）地规格化原生 XML 数据库的数据。将原本应该驻留在几十个关系模型表中的数据存储到一个 XML 文档类型中的做法是十分常见的。

现今的大多数 XQuery 实现执行连结（join）操作的效率很低，即使是一个只涉及几千条记录的简单查询都需要耗费大量的、令人难以接受的处理时间。这就使得下面这条决定是否应该规格化数据的标准很明确：永远不要规格化数据，以免受支持的查询需要执行连结操作来选择记录。

受支持的查询是这样一种查询，即您可以合理地预期用户怎么对待您的数据。例如，如果构建一个用于销售录像带的应用程序，您可能预期用户会查询标题中包含某个关键字并且由某个导演执导的所有视频。因此，您肯定希望表示视频的 XML 文档包含视频标题和导演姓名。另一方面，对于这个特定的应用程序，您也许不希望支持用户查询标题中包含某个关键字并且由纽约出生的某位导演执导的所有视频。换句话说，对于这个视频应用程序示例，如果您拥有导演的详细信息（不仅仅是导演姓名），可以考虑将这些信息保存在一个单独的 XML 文档中。

使用以下两个互相链接的 XML 文档类型来描绘数据库：video-rec 和 director-rec，前者带有关于视频的信息，其中包含一个 director-rec 标识符；后者带有关于导演的信息。要查询标题中包含某个关键字且导演出生于纽约的记录，必须执行连结操作以选择记录。如前所述，也可以不支持这种类型的查询，因为这是一种更侧重于数据挖掘的查询，而不是大多数浏览在线视频商店的用户通常执行的查询类型。但是，除非您有具体原因需要将关于导演的详细信息移动到一个单独的文档类型中，否则应该将这些信息保存在 video-rec 文档中。

尽管在原生 XML 数据库中执行连结操作来选择记录总是低效的，但是在转换搜索结果中的数据时从多个 XML 文档提取数据通常是可取的。我此前描述的视频商店能够轻松高效地呈现包含导演出生地的结果，尽管获取这个地址需要从原始搜索结果之外的文档提取数据。以这种方法组装结果，所需的操作仅限于应用程序已经选择和计划显示的少数几条记录，与常规的搜索查询中连结多个文档类型所需的资源相比，这种方法的计算和内存需求可以忽略不计。