 [转帖]管理 XML 数据
介绍如何管理 XML 文档集合
关于如何处理 XML 文档的文章已经有很多，其中包括如何用 XPath 搜索 XML 文档、如何用 XSLT 转换 XML 文档、如何用 CSS 设置样式，以及如何用 DOM 创建 XML 文档。但是随着 XML 日渐流行，XML 文档开始在系统中泛滥（无论是否愿意），并带来了一个更大的问题：如何管理 XML 文档集合？如何处理成千上万甚至上百万的 XML 文档，如何找到所需的内容，如何组织、索引、搜索、供应、交叉引用、更新 XML 文档，以及如何用其他方式管理大中型 XML 数据集合呢？
本专栏将尝试为这些问题提供有用的答案。
数据管理的四项任务
数据管理的基本任务不会仅仅因为保存在 XML 中而发生改变。大致上有四项任务：存储、搜索、检索和显示。当然，所有这些任务是互相联系的，处理一项任务的方法会影响到其他三项任务。
存储
您总得把数据放在某个地方。到 2005 年，桌面机驱动器一般能存储数百吉字节；RAID 阵列很轻松地跨过了 TB 的门槛；甚至膝上型电脑的硬盘也可以有几十 GB 的容量，因此这个问题不像以前那样突出了。您可以将大量的东西塞到文件系统中，但是如果需要取出数据会怎么样呢？搜索和检索方面的困难意味着，即使使用文件系统作为基本的数据存储器（很可能不是），仍然需要考虑如何安排和组织文件。
奇怪的是，除了一个文档对应一个文件的方式之外，很少有人注意到其他的 XML 存储方式。很多书籍最多在口头上说说，认为可以用实体或者 XInclude 将文档分解成多个文件。很少有人提到用单个文件或其他容器存储多个文档的可能性，虽然人们发现在很多情况下这样做至关重要（比如日志）。除了每个文档一个文件之外，还有其他的存储机制。事实上，某些最有希望的存储机制没有从传统的意义上使用文件这个概念。
搜索
目前为止，数据管理中最棘手的问题是如何发现信息。如果只知道要找的数据在某个硬盘上的一个文件中，而这个硬盘上有成千上万个没有索引的、采用“p095893t.xml”这类名称的文件， 那么您的麻烦来了，即使磁盘和 CPU 真的真的非常快。如果需要知道那个集合中的多个文件而不是一个文件的内容，麻烦就更大了，除非每一个都看一看。如果每秒钟需要做几十次这种查询，那么您玩完了。这根本办不到，甚至在纯文本集合中都办不到。解析 XML 的开销只会进一步加剧这个问题。这就是数据库要建立索引的原因，一般的查询不需要读取数据库中的每个字节。
关系数据库的数学基础和数十年经验的结合优化了这类查询，使搜索和查询成为 SQL 数据库最为出色的一个领域。但是，XML 文档很少非常适合某种关系结构。虽然可以分解文档，将它们存储在关系表中，但这样更像是停车的时候把汽车拆成零部件，放到精心贴好标签的架子上，然后出门的时候再重新组装成汽车。花的时间也差不多。高效实用的 XML 文档索引要求利用这些文档的自然结构，而这种结构很少与关系数据库的行和列一致。所幸的是，人们已经对这个领域开展了大量的研究，结果看来大有希望。
检索
在成功地存储了数据，并找到存放数据的地方之后，现在需要再把数据取出来。从存储中检索数据通常不是最大的问题（除非存储的时候将文档分解成了小片，现在又需要将这些小片组合成一个大胖子）。但是这方面也并非没有自己的问题。比方说，如果存储数据的物理介质坏了怎么办？备份在这时变得很重要。如果网络断开，或者整个服务器坏了怎么办？在不同的地方有冗余系统吗？如果有的话，又如何保持同步呢？允许哪些人看到存储的数据呢？您当然不希望一般人看到工资记录，H1-B 雇员干同样的活工资却低 20% —— 无论用 XML 还是其他任何格式。访问控制非常重要（虽然坦白地说，对于存储和查询，这也是一个问题）。
显示
最后一步是向用户显示发现、查询和检索的文档。这又开始回到一些经过很好研究的领域。关于如何使用 XSLT、CSS、XHTML、SVG 和其他技术向一个或多个人显示单个文档，已经有很多这方面的论述。我不想再老调重弹。但是，在边缘地带仍然有一些未探索的领域。比方说，假设要查看多个而不是一个文档，或者要查看几十甚至数千个文档，那么如何用一种易于访问的方式组织多个 XML 文档呢？
简史
实际上，这四项基本任务与关系数据库、网络数据库、纯文本和索引卡片所执行的任务是相同的。（我最近参与的 Louisiana State University Museum of Natural History (LSUMNH) Bird Observation Collection 数据库可以上溯到 50 年以前，这些数据完全保存在纸上。）至少从埃及的多勒密二世和亚历山大图书馆建立开始，人们就开始管理大量数据的集合，而且至少有一个巴比伦图书馆可以追溯到 1000 年前。我希望今天的图书馆员要比亚历山大时期的人们知道更多关于如何管理数据的知识，但有时候很奇怪的是这方面的变化很小。事实上，确定一些思想是本质性的还是仅仅是昙花一现的一种办法是：看看这些思想确实是新思想，还是新瓶装旧酒。（我说的是“仅仅”，但那些老的、经过验证的思想仍然值得学习和坚持。新的思想往往在短时间内闪出火花，很快就熄灭了。）
虽然人们管理数据有上千年的历史了，随着技术变迁，新的数据形式确实需要新的工具。新的工具可以使搜索和检索数据的任务更简单一些。创建 LSUMNH 卡片文件数据库的时候，索引卡片是 1947 年最时新的技术，但是这象技术不能很好地适应互联网时代；事实上，人们已经在筹备将该数据集计算机化的计划。随着越来越多的数据是用 XML 编辑、交换和提供的，信息学家需要新的工具来使用 XML 结构来进行存储、搜索、访问控制等操作。一些工具存储实际的 XML 文档，另一些则仅仅使用 XML 文档明确的结构，来传达关于如何以其他格式存储内容的决策。但是 XML 结构确实传达了比非标记文本更多的含义，如果可能的话，利用这种精心安排的结构是合情合理的。
过去二十年中，关系数据库在管理数据方面取得了空前的成功。关系数据库有坚实的数学理论支持，优势非常明显。更重要的是它在实际应用中非常好（虽然实际关系系统的突出性能常常以完全实现数据模型为代价，这一点令关系纯粹论者非常恼火）。实际上，关系数据库如此成功，以至于有时候开发人员忘记了存储数据的其他方法。与流行的看法相反，世界上大多数数据并没有存储在关系数据库中。大量的数据仍然尘封在旧式的网络和层次数据库中，比如 IDMS 和 IMS。更多的数据则保存在您可能根本不认为是数据库的东西中：普通的文本文件、电子表格、电子邮件、Microsoft® Office 文档，等等，这些文档都存储在不同计算机的文件系统中。与传统的关系方法相比，大部分（虽然不是全部）此类数据更便于快速有效地使用 XML 和 XML 数据管理技术存储。
未来展望
在未来的数周或几个月中，我将探讨这里提出的这些问题。我将查看大量主题，这些主题在每次只考虑处理一个文档时没有多大意义，但在管理文档集合时非常重要。将研究的主题包括：
• 文件扩展名和 MIME 媒介类型
• 使用目录管理模式和样式表综合资料库
• 本地 XML 数据库
• XQuery
• XUpdate
• 在关系数据库中存储 XML
• 在 XML 文档中存储关系表
• 管理结构异常的 HTML
• 在 Web 上提供 XML 文档
• 内容管理系统
• XML 流和日志
• 版本控制
我将讨论管理 XML 文档集的理论和实践。按照计划，本栏目的内容包括：如何分析需求、如何配置现有的系统来获得更好的性能和可维护性、分析将来可能会用到的新技术。我将考察一些老的问题，如备份和版本控制，着重分析新的 XML 风格的数据要求这些系统所做的更改。我将考察过去可能没有出现的新问题，比如说，确保某个组织的模式在分布在世界各地的分支机构的多台独立计算机上保持同步。
这方面的内容还有很多，不是几篇文章就能说得完的。但即使存在进一步加重担子的危险，我还是要请您把关于管理 XML 数据的问题、建议和经历告诉我。您的组织中遇到了什么难解的问题？过去有什么事情让您伤神，是什么阻止您把数据转移到 XML 中？最重要的是，您需要知道什么别人还没有讨论过的东西？请将这些告诉我。我会设法予以解答。如果某个问题具有共性，以后的几个月中我将在本栏目中对该问题进行答复
|
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
XML.ORG.CN讨论区 - 高级XML应用 → 『 XML 与 数据库 』 → [转帖]管理 XML 数据
(订阅本版)
2005/5/12 12:14:00
顶端 
XML好慢阿，等待新算法出来(25字) － d_hao20@ustc.edu，2005年5月19日
新浪微博
