误解：XQuery 不是产品，仅仅是很多层中的一层

　　如果需要管理和操纵 XML 数据，XQuery 就是程序库、应用程序编程或者服务栈所提供的功能规范。但是，底层的 XML 存储、检索和索引机制造成了 XQuery 实现的功能、性能和可伸缩性的很大差异。比如，最初曾经尝试将 XML 数据保存在关系数据库的 varchar2 字段中，然后简单地增加一个 XQuery 引擎层，结果查询性能很差。这就导致了在内容管理、数据持久性、Web 服务和面向服务架构（SOA）、数据仓库、联机分析处理（OLAP）、提取/转换/加载（ETL）、企业应用程序集成（EAI）和供应方管理等方面形成了专门的 XQuery 解决方案。

　　误解：XQuery 对于提高面向服务架构（SOA）的性能、控制复杂性没有多大用处

　　构建的系统要处理大量 XML 数据时，软件架构师和开发人员借助 XQuery 解决性能和复杂性问题。考虑下面的情况和相应的 XQuery 解决方案：

　　早期的研究表明，基于 ebXML 和 UBL 的服务中有效负载的数量和 XML 模式的复杂性呈爆炸性增长，在这里 XQuery 可以发挥重要作用。

　　XQuery 在很大程度上增强了 UDDI 解决方案，因为可以更好地管理和控制 UDDI 注册中心列出的资源。

　　软件架构师发现，滞后（soft-moving）数据缓存能够改善 SOA 的性能。类似的网页边缘缓存中，收到很多对相同信息请求的服务可以使用 XQuery 引擎临时缓存 XML 数据。Xquery 实现一般同时提供 Xquery 脚本能力和数据持久性或者存储设施。服务将 XQuery 公开为一种服务，并使用底层的 XQuery XML 数据库临时缓存 XML 数据。

　　另外，在供应链应用领域，XQuery XML 存储和检索有可能对加速整个系统的性能发挥重要作用。设想一下，在供应链事务中需要跟踪每个产品，而且业务关系使用 XML 文档描述，如果能利用基于 XQuery 的高级存储和检索能力会是什么样的。

　　误解：XQuery 在数据转换中起不了多大作用

　　当采用新模式或者现有模式发生变化时，XQuery 可以在数据转换中发挥很大的作用。对于需要建立供应链应用程序的企业而言，成本最大的部分就是转换不兼容的消息格式。比如，假设买方采用了 RosettaNet 这样的标准，和原来内部开发的模式完全不同。作为供应商，就需要供应链应用程序兼容 RosettaNet 格式，但是又要避免将现有系统转移到 RosettaNet 的成本和风险。XQuery 可以帮助您迁移到新标准，又不会终止现有的销售操作。

　　XQuery 提供了一种方法，可以将现有的模式映射或转换到 RosettaNet 格式，而不需要编写大量的新代码库。相反，只需要编写一个 XQuery，将现有的响应数据转化成 RosettaNet 响应。

　　误解：XQuery 和联机分析处理（OLAP）以及数据仓库应用程序没有什么关系

　　XQuery 确实为 OLAP 和数据仓库应用程序提供了必要的链接能力。比如，一般企业通常有多个数据仓库来跟踪和分析公司数据。这些仓库就像是杂乱的地下室，需要花费人力、资金和专门技能才能挖掘出业务知识。将一个地下室和另一个联系起来需要很大的工作量，成本很高。XQuery 提供了一种解决方案，通过在多个数据仓库之间建立基于查询的连接来帮助 OLAP。比如，一个数据仓库保存发送给日用零售店的产品，另一个数据仓库保存零售店提供的产品支持电话。 XQuery 通过显示哪些产品造成最多未解决的支持电话，建立了这两个数据仓库之间的桥梁。这就证明了 XQuery 在逻辑数据仓库、分析、提取/转换/加载（ETL）和企业应用程序集成（EAI）方面的优势。

　　神话：XQuery 不能处理大型数据集，永远赶不上关系数据库的运行速度

　　从很多方面，XQuery 标准业界都将 Internet 看作是一个大型的分布式 XML 数据库。从这种角度出发，这种查询语言要具备使用户在一个或多个相关文档中发现数据的浏览能力。从数据库的角度看， XQuery 是大型数据集上的结构化和基于内容的查询工具，这一数据集就是世界范围内的 XML 数据库。从这个角度来说却是非常大。

　　XQuery 解决方案的可伸缩性和性能取决于 XQuery 实现的目标。比如，有些 XQuery 实现强调内容管理和集成服务。这类实现最适合于向有限受众发布 Web 站点和 Web 门户。以 XML 数据库功能为中心的 XQuery 实现最适合高效地处理大型数据集。

　　要了解 XQuery 实现的主要目标，最简单的办法是查看其来源。比如，观察 XQuery 工作组可以看到两类完全不同的参与者：从 XML 文档领域转向 XQuery 的人和将 XML 作为数据的人。面向文档的成员具有 SGML 背景，强调快速访问相对较少的 XML 数据。面向数据库的成员具有层次、关系和 XML 数据库的背景，认为对开发人员最重要的是索引、文本搜索扩展、事务和两阶段提交、外部索引和 SDK/API。

　　误解：XPath 和 XQuery 不是一回事吗？

　　实际上，XQuery 建立在 XPath 和 XSLT 的基础之上。软件架构师和开发人员使用 XPath 作为一种查询语言，发现 XML 文档中的元素并使用 XSLT 将其转换成 XHTML 或者另一种 XML 格式。比如，开发人员使用 XPath 在 XML 文件中发现病人的牙科记录，然后使用 XSLT 将病人信息打包成 HTML 显示在浏览器中。如果数据已经保存为 XML 格式，这种方法很好，但是 XPath 和 XSLT 只能用于 XML 文件。

　　XPath 是面向选择的，XSLT 则面向转换；这两种技术仍需要一种有效的方式来选择、连接并将数据转化成需要的形式。XQuery 能够满足应用程序的数据需求：可以访问多个数据源、选择信息和连接数据。这种技术同样适用于非 XML 数据，包括表单、网页和其他结构松散的数据。

　　误解：XQuery 没有更新机制

　　XQuery 规范确实没有包含更新机制。而且在撰写本文的时候，XQuery 工作组的主 Xquery 规范正处于“Last Call”状态，没有工作组成员愿意花费时间来更新规范。我希望 XQuery 规范最终将采用 SQL 风格的方法。更新很可能用一组独立的操作表示，模仿和支持现有的关系数据库命令。但是，一些实现者和现有的实现提供了一种更加自由的方式来利用 XQuery 组成更新。

　　必须指出的是，多数 XQuery 实现都提供了自己的更新机制。比如，一种流行的 XQuery 引擎通过扩展提供了对 XML 数据和非 XML 数据的 Create、Read、Update 和 Delete (CRUD) 操作。

　　神话：XQuery 规范永远不会成为 RFC

　　看来似乎如此，但是撰写本文的时候， XML Query 工作组和 XSL 工作组的 XQuery、XPath 和 XSLT 语言都进入了“Last Call”状态。而且已经存在了多种成熟的 XQuery 产品。

　　神话：XQuery 支持基于记号的文本搜索

　　虽然 XQuery 全文检索规范确实定义了基于记号（token-based）的文本检索， XQuery 工作组有意留下了一些方面未作规定。比如， XQuery 没有提供加载文档和查看可用文档列表的标准机制。按照我的看法，不规定每个方面为 XQuery 带来了一些可塑性。当前的 XQuery 实现关注的焦点不同，底层的数据管理设施也有很大差异。 这种可塑性使 XQuery 不仅适合作为数据库搜索引擎，还可用于队列筛选。非常强大。

　　结束语

　　总之，XQuery 看来不错，减少了创建 XML 服务需要编写的代码量。更大的 XQuery 系统提供了查询 XML 文档的统一方式，包括 XML 选择、序列化、全文搜索和函数性数据建模。XQuery 规范工作组的工作还将继续，为使用 XML 的开发人员带来更多的好处。

上一页 1 2 下一页 相关热词搜索：

收藏到网摘：

上一篇：巧解Session cookie 下一篇：javascript调用XML制作连动下拉框 收藏 将此文推荐给朋友