如果您在使用 XML、Web 或者面向服务的架构QService Oriented ArchitectureQ?A class=bluekey target=_blank>SOAQ，那么很可能会?XML Query (XQuery) 标准的制定中受益。虽?XQuery q未批准为正式标准，但已l有几十U实现每天都在帮助Y件架构师和开发h员了。即Ş成的 XML 文档查询标准包括了下一?XML 选择语言QXPath 2Q、XML 序列化、全文检索和功能?XML 数据建模。这栯模的目免不了有很多话和误解需要揭Iѝ下面是围绕着 XQuery 的一些常见的话和误解?
误解Q数据库公司?XQuery 视作其核心业务的直接Ҏ
数据库公司将 XQuery 看作一个机会，与其核心解决Ҏ互相补充?BR>
对于软g架构师和开发h员而言QXQuery 提高了生产率Q增加了敏捷性。工具供应商q切希望支持 XQuery 是合情合理的?BR>
对于开发h员来_XQuery 很像 SQLQ自然而然地对两者加以比较。何况越来越多的数据正?XML 标记Q这p使数据库公司在品中增加 XML 存储、持久性和查询的能力。XQuery 拥有如此众多的开发h员支持，以至?IBM ?Oracle 它们的角逐放在一旁，转而扩展其核心数据库品以提供 XQuery 能力?BR>
数据库公怹看到了成为第一个充分利?XML 格式的数据库供应商（从而最l成为市场霸主）所带来的机会?目前存储在关pL据库中的数据按照行和字段q行了规格化。在 XML 世界中，每一行包含无限多个字D，每个字段都是?子层ơ结构中的一部分。最先提供高性能?XQuery 灉|性的供应商将赢得一个巨大的新市场?BR>
一个证据是QXQuery ?IBM ?Oracle 团结在一P不再是凶狠的ҎQ，合作提出 JSR 225Q参阅参考资料）Q?XQuery API for Java (XQJ)。在 .NET q一边，Microsoft ?IBM 共同向万l网联盟QW3CQ提交了 XQuery 试包?BR>
话QXQuery 代?XSLT
XQuery ?XSLT 都有_多的开发h员支持，共存下厅R事实上QXQuery 1.0 ?XSLT 2.0 最新规范的开发是先后q行的?BR>
XQuery ?XSLT 交叉之处在于它们解决的问题：XML 数据转换、XML 集合联邦?XML 数据高查询。开发h员仍仍将看到关于q两U技术的争论Q包括各U各L话和误解。比如，我常常听?XQuery 能够一ơ查询多个不同的源文Ӟ因此要比 XSLT 优越得多。事实上QXSLT 2.0 处理E序允许在输入队列中l出多个节点?XSLT 1.0 ?document() 函数Q可以在一ơ{换中讉K多个源文ӞXSLT 2.0 q支持新?collection() 函数。我也常常听到这L说法Q虽?XQuery 的语法看h更好Q但是缺?XSLT 模板风格的模式匹配。虽然这也许是真的，但我坚信 XQuery 也会增加q一功能。最l，开发h员可以预期这两种技术的改进和竞争将使它们的功能和能力不怸下?BR>
最后，q有开发h员头脑迟钝的问题。参加的那些 XSLT 会议让我感到Q我q没有真正理解它?XSLT 的{换语法ƈ没有?Java ?Jython 中通常所用的 main() ?start Ҏ。我有时候将 XSLT 看作一U脚本，说明q没有真正理?XSLT。XQuery 看v来很?SQLQ解决了很多我不得不从书架上L{案的问题?BR>
话QXQuery 代?SQL
XQuery 最适合?XMLQ就?SQL 最适合于关pL据?XQuery 为需要访问、挑选、集成和转换一个或多个 XML 集合的应用程序提供了cM?SQL 的查询能力。虽?XML 的狂热者可能将世界上的一切都看成是用 XML 标签~码的，单关pL据库模型仍然Ҏ蒂固Q世界上大部分数字数据是用由行和列组成的表来q行~码的。SQL 不会很快地消失。相反已l出?XQuery 扩展Q将 SQL 调用的结果看作是 XML 文档集合的一部分?BR>
如上所qͼXQuery 对于 XML 像 SQL 对于关系数据库。但是，有些时候甚至相对于关系数据库而言QXQuery 更容易用。比方说Q对于一般开发h员，使用 SQL 创徏输出l果为新 XML 文档的多表外q接查询要比~写 XQuery 复杂得多?BR>
XML 的普及已l迫使标准团体工作组扩展 SQL 规范Q以便纳?XML 处理功能?SQLX Group、INCITS H2 组?ISO/IEC JTC1/SC32/WG2 ?SQL/XML 标准化都在致力于扩展 SQL 标准Q其能够处?XML 数据?BR>
误解Q采?XQuery 必须攑ּq程性编E而{向面向对象编E?/B>
对于 XQuery 来说Q过E性脚本语a和面向对象的~程语言都是一L。如果愿意编?PHP 脚本Q仍然可以l这样做。多数现有的~程语言都有 XQuery 实现?BR>
XQuery l开发h员带来的好处是减了执行查询所需要的代码量。有时候关pL据在两个或更多的数据库中Q开发h员需要生成报表来昄两个数据库的q。喜Ƣ?Python q类q程性编E语a的开发h员可能要~写 100 或更多代码行来检索、解析和处理数据。当然也可以~写几行 XQuery 来完成?BR>
话QXQuery ?JDOM、JAXP 和其?XML 解析 API 更难?/FONT>
XQuery 用于 XML 数据q不?XML 解析 API 更难。JDOM、JAXP 以及其他 XML 解析 API 提供了处?XML 数据?Java 代码和方法。很多面向对象的设计模式都准备编写处?XML 文档复杂性的对象。编?Java 对象需要时间、精力和专门的技能。底?XML 数据格式的Q何细微变化都需要修改对象。XQuery 的拥护者可以肯定地_和?JDOM ~写 Java 对象相比QXQuery 脚本能够更快地发现应用程序需要表C的 XML 数据。另外，很多 XQuery 库都提供?Java 接口Q因此可以在 Java cM~写 XQuery 代码来获得结果集Q就像调用一个方法一栗然后让 Java cd理结果?BR>
话QXQuery 难以学习
使用 Java?NET 和其他语a的Y件开发h员发?XQuery 很容易学。XML 有很多不那么优美的地方，包括从早期的 SGML 标准l承下来的那些部分?XQuery 使用一l简z的命oQ很Ҏ处理 XML。虽然一般开人员要掌?XQuery 面着一些困难，但是学习曲线q不很陡峭，也不ѝ?BR>误解QXQuery 不是产品Q仅仅是很多层中的一?BR>
如果需要管理和操纵 XML 数据QXQuery 是E序库、应用程序编E或者服务栈所提供的功能规范。但是，底层?XML 存储、检索和索引机制造成?XQuery 实现的功能、性能和可伸羃性的很大差异。比如，最初曾l尝试将 XML 数据保存在关pL据库?varchar2 字段中，然后单地增加一?XQuery 引擎层，l果查询性能很差。这导致了在内容管理、数据持久性、Web 服务和面向服务架构（SOAQ、数据仓库、联机分析处理（OLAPQ、提?转换/加蝲QETLQ、企业应用程序集成（EAIQ和供应方管理等斚w形成了专门的 XQuery 解决Ҏ?BR>
误解QXQuery 对于提高面向服务架构QSOAQ的性能、控制复杂性没有多大用?/B>
构徏的系l要处理大量 XML 数据Ӟ软g架构师和开发h员借助 XQuery 解决性能和复杂性问题。考虑下面的情况和相应?XQuery 解决ҎQ?BR>
早期的研I表明，Z ebXML ?UBL 的服务中有效负蝲的数量和 XML 模式的复杂性呈爆炸性增长，在这?XQuery 可以发挥重要作用?BR>
XQuery 在很大程度上增强?UDDI 解决ҎQ因为可以更好地理和控?UDDI 注册中心列出的资源?BR>
软g架构师发玎ͼ滞后Qsoft-movingQ数据缓存能够改?SOA 的性能。类似的|页边缘~存中，收到很多对相同信息请求的服务可以使用 XQuery 引擎临时~存 XML 数据。Xquery 实现一般同时提?Xquery 脚本能力和数据持久性或者存储设施。服务将 XQuery 公开ZU服务，q用底层的 XQuery XML 数据库时缓?XML 数据?BR>
另外Q在供应铑ֺ用领域，XQuery XML 存储和检索有可能对加速整个系l的性能发挥重要作用。设想一下，在供应链事务中需要跟t每个品，而且业务关系使用 XML 文档描述Q如果能利用Z XQuery 的高U存储和索能力会是什么样的?BR>
误解QXQuery 在数据{换中起不了多大作?/B>
当采用新模式或者现有模式发生变化时QXQuery 可以在数据{换中发挥很大的作用。对于需要徏立供应链应用E序的企业而言Q成本最大的部分是转换不兼容的消息格式。比如，假设买方采用?RosettaNet q样的标准，和原来内部开发的模式完全不同。作Z应商Q就需要供应链应用E序兼容 RosettaNet 格式Q但是又要避免将现有pȝ转移?RosettaNet 的成本和风险。XQuery 可以帮助您迁Ud新标准，又不会终止现有的销售操作?BR>
XQuery 提供了一U方法，可以现有的模式映射或{换到 RosettaNet 格式Q而不需要编写大量的C码库。相反，只需要编写一?XQueryQ将现有的响应数据{化成 RosettaNet 响应?BR>
误解QXQuery 和联机分析处理（OLAPQ以及数据仓库应用程序没有什么关p?/B>
XQuery 实?OLAP 和数据仓库应用程序提供了必要的链接能力。比如，一般企业通常有多个数据仓库来跟踪和分析公司数据。这些仓库就像是杂ؕ的地下室Q需要花费h力、资金和专门技能才能挖掘出业务知识。将一个地下室和另一个联pv来需要很大的工作量，成本很高。XQuery 提供了一U解x案，通过在多个数据仓库之间徏立基于查询的q接来帮?OLAP。比如，一个数据仓库保存发送给日用零售店的产品Q另一个数据仓库保存零售店提供的品支持电话?XQuery 通过昄哪些产品造成最多未解决的支持电话，建立了这两个数据仓库之间的桥梁。这p明了 XQuery 在逻辑数据仓库、分析、提?转换/加蝲QETLQ和企业应用E序集成QEAIQ方面的优势?BR>
话QXQuery 不能处理大型数据集，永远赶不上关pL据库的运行速度
从很多方面，XQuery 标准业界都将 Internet 看作是一个大型的分布?XML 数据库。从q种角度出发Q这U查询语a要具备用户在一个或多个相关文档中发现数据的览能力。从数据库的角度看， XQuery 是大型数据集上的l构化和Z内容的查询工Pq一数据集就是世界范围内?XML 数据库。从q个角度来说却是非常大?BR>
XQuery 解决Ҏ的可伸羃性和性能取决?XQuery 实现的目标。比如，有些 XQuery 实现内容理和集成服务。这cd现最适合于向有限受众发布 Web 站点?Web 门户。以 XML 数据库功能ؓ中心?XQuery 实现最适合高效地处理大型数据集?BR>
要了?XQuery 实现的主要目标，最单的办法是查看其来源。比如，观察 XQuery 工作l可以看Ccd全不同的参与者：?XML 文档领域转向 XQuery 的h和将 XML 作ؓ数据的h。面向文档的成员h SGML 背景Q强调快速访问相对较的 XML 数据。面向数据库的成员具有层ơ、关pd XML 数据库的背景Q认为对开发h员最重要的是索引、文本搜索扩展、事务和两阶D|交、外部烦引和 SDK/API?BR>
误解QXPath ?XQuery 不是一回事吗？
实际上，XQuery 建立?XPath ?XSLT 的基之上。Y件架构师和开发h员?XPath 作ؓ一U查询语aQ发?XML 文档中的元素q?XSLT 其转换?XHTML 或者另一U?XML 格式。比如，开发h员?XPath ?XML 文g中发现病人的牙科记录Q然后?XSLT 病Z息打包成 HTML 昄在浏览器中。如果数据已l保存ؓ XML 格式Q这U方法很好，但是 XPath ?XSLT 只能用于 XML 文g?BR>
XPath 是面向选择的，XSLT 则面向{换；q两U技术仍需要一U有效的方式来选择、连接ƈ数据{化成需要的形式。XQuery 能够满应用E序的数据需求：可以讉K多个数据源、选择信息和连接数据。这U技术同样适用于非 XML 数据Q包括表单、网和其他l构松散的数据?BR>
误解QXQuery 没有更新机制
XQuery 规范实没有包含更新机制。而且在撰写本文的时候，XQuery 工作l的?Xquery 规范正处于“Last Call”状态，没有工作l成员愿意花Ҏ间来更新规范。我希望 XQuery 规范最l将采用 SQL 风格的方法。更新很可能用一l独立的操作表示Q模仿和支持现有的关pL据库命o。但是，一些实现者和现有的实现提供了一U更加自q方式来利?XQuery l成更新?BR>
必须指出的是Q多?XQuery 实现都提供了自己的更新机制。比如，一U流行的 XQuery 引擎通过扩展提供了对 XML 数据和非 XML 数据?Create、Read、Update ?Delete (CRUD) 操作?BR>
话QXQuery 规范永远不会成ؓ RFC
看来g如此Q但是撰写本文的时候， XML Query 工作l和 XSL 工作l的 XQuery、XPath ?XSLT 语言都进入了“Last Call”状态。而且已经存在了多U成熟的 XQuery 产品?BR>
话QXQuery 支持Z记号的文本搜?/FONT>
虽然 XQuery 全文索规范确实定义了Z记号Qtoken-basedQ的文本索， XQuery 工作l有意留下了一些方面未作规定。比如， XQuery 没有提供加蝲文档和查看可用文档列表的标准机制。按照我的看法，不规定每个方面ؓ XQuery 带来了一些可塑性。当前的 XQuery 实现x的焦点不同，底层的数据管理设施也有很大差异?q种可塑性 XQuery 不仅适合作ؓ数据库搜索引擎，q可用于队列{选。非常强大?BR>
l束?/B>
MQXQuery 看来不错Q减了创徏 XML 服务需要编写的代码量。更大的 XQuery pȝ提供了查?XML 文档的统一方式Q包?XML 选择、序列化、全文搜索和函数性数据徏模。XQuery 规范工作l的工作q将l箋Qؓ使用 XML 的开发h员带来更多的好处
]]>