XML 与数据库之我见

和大多数人不同的是，大家一般是先学数据库，后学 XML，而我却是反过来。MsSQL 究竟如何，自己一直没有看过，学过的也是和 PHP 配合使用的 MySQL，有些感触，谈出来，与大家分享讨论一下。

XML 研发之初最原始的目的就是完整的保存数据结构和内容，单从这一点来看，用 XML 做数据库无可厚非，也确实有这样的例子：MSDN Online 的菜单结构就是使用 XML 完全保存的。

但是我们应该注意到的是，XML 并非是一个万能的产物，或许等过了五年、十年，等到 XML 的结构方法更加优化(为什么说不优化后讲)，等到 XML 的读写方法更加方便简洁，等到 XML 的数据保存更加安全的时候，我们再用其作为数据库使用，那真的是一点问题都没有了，但现在还不成熟。

虽然我很推崇 XML，但我们不能不正视 XML 现在的不成熟性，当然，我所谓的不成熟性，是拿 XML 自身的短处与数据库的长处作比的。

其一：XML的结构方法不够优化。
大家都知道，XML 是以纯 Unicode 码的形式保存在 ASCII 文档中的。如果只有一个根元素和唯一一个子元素还简单。但如果涉及到一个完善的复杂的元素系统，劣势便出来了。为了表述上的需要，你可能不得不使用诸如 MyFavoriteSongsItem 之类的标签名称。那么在这样的一个完善的元素系统下保存一个 5KB 大小的 XML 文档，其中真正需要保存下来的数据能够有多少呢？

有些朋友或许会用 Binary 形式的位码作为元素名称，如此一来，既然你用位码作为元素名称以求小空间占用，你也不会不用另外的位码来取代 <> </> 的结构。这样的文档确实从 XML 思想而来，但其是否能够称之为严格的 XML 文档呢？是否能讲这样的文档应用到常见的 DOM XSLT 中呢？唯一或许可用的就只有 SAX 了。我们只能称呼为“继承了 XML 思想的特殊应用的特殊文档”。

结构方法既然有无比强大的自由性，不能不丢失一部分便携性了。


其二：XML 读写方法不如数据库简便。
列举一下常见的用于读取和写入 XML 的方法，除了 FSO 一类的方法，属于纯 XML 技术的当属 DOM XSLT SAX 三大类。我们都知道，出于 XML 保存在 ASCII 文本中的原因，这三种方法都是将整份文档读入内存的。那么一个数据库文件我们可以写到 2G、3G，一份 XML 文当我们敢写这么大么？

确实，XML Section 这一 XML 片断读写的技术正在开发中。我也在焦急地等待着呢，但在研发完成成为标准，哪怕成为推荐前，我们都不能不正视这个问题。而数据库因为本身出于大规模数据集成的考虑，都有属于自己的直接从硬盘磁道读取写入数据的能力。这一点，XML 相形见拙。


其三：XML 数据不够安全。
要说的是， XML Security 这一技术却是也是在发展，与上面提到的 XML Section 技术一起，是 XML 未来向传统数据库挑战的资本(详细资料可以在 http://www.w3c.org/ 获得)。但在其获得长足发展前，我们唯一能够做到的就是在读写 XML 文当前自行加密解密其内容。而数据库不同，首先它有自身的服务器，可以做到初步防范，其次还可以对某个数据库甚至某张特定的表进行加密。这又是 XML 相对于数据库的缺陷之一。



综合上面主要三点，我的态度就是无需拿 XML 的短处和数据库的长处相提并论。XML 尤其自身的优势，仅在 WEB 应用一门上，便具备 HTML 和其他附加技术所无与伦比的简易性、通用性和便携性。或许我说得不够准确，但是可以想象一下，从数据库资料直接生成 XML 交由统一的 XSLT 处理，和从后台获得固定的 XML 文档通过 DOM 解析究竟哪个更有优势呢？无疑是前者，这是由技术本身所确定下来的。

因为马上要坐上回家的火车了，我就不再多说废话。如果以上见解中有错误，欢迎大家指正，如果有失偏颇，也欢迎大家指出讨论。

:P

看来我目前的XML应用还初一个非常原始的阶段（script+DOM），看来要看看XSLT的应用了.......

支持楼主.

哈哈... 好久没见到 SNAK 生了.....
  好文章! 顶先.........

鼓掌，支持蛇蛇的意见，另外这里有一篇更加全面的：
http://www.onestab.net/x/XMLAndDatabases_zh.html