xml db的前途

我个人很喜欢xml db 而且已经开始慢慢放弃 sql jdbc hibernate这些东西.
在数据库方面我有90%的时间用在xql xsl上.

xml db优势

1 结构灵活
这是我开始用xml db的原因 在rdb中 任何字段变动都会带来麻烦 但在xml db中 这是轻而易举的事 没有任何结构上的束缚.

2 转换灵活
从xml db中直接取得的xml 要比从rdb中取得的rs好处理 用一个xsl就可以将结果转化为自己需要的格式.

3 xquery
我现在感觉xquery比sql更方便

4 ajax
exist可能会是第一个支持ajax应用的数据库 xml db是ajax的最佳搭档

5 xml开发框架
cocoon经过多年的发展 已经相当成熟  用cocoon + xml db开发的系统在灵活性 可定制性 方面是现有的其它框架 struts zope无法匹敌的.

xml db缺点：

1、xml db的存取效率非常低
道理很简单，以Oracle XML DB为例，最终还是转换为table存储的，xml db的灵活是以将元素信息保存在meta table中为代价的，每次从数据库存取，在数据库端都无法预编译。

2、xml在Java中运算效率也很低
在没有必要一定转换为XML格式的情况下非要用XML，还不必要的增加了程序的复杂度。

3、支持XML DB的数据库还很少，而且每个数据库的支持方式也不一致。

1 我反驳不了 确实效率低 但速度提高很快. (Berkeley xmldb速度就很快). oracle rdb最开始就是由于效率问题不被重视的.

2 这是因为你习惯用传统的java框架 我认为以后被迫用xml的地方会更多 淘汰的不是xml 而是成熟的不得了的struts spring框架.

3  都支持xquery1.0 不同点也就是xupdata方面的微小差异 根本不成问题 xupdata也简单的要命.

如果信息本身恰好是用xml描述的,那当然很愿意用xml db来存取(因为程序本身恰好很喜欢上xml,也不用废力去考虑如何把xml映射到rdb里);如果不是,那就不必要把信息非用xml db来存取啦.

xhtml, ajax view, xul, svg web应用中xml肯定是越来越多 直接用xml框架开发 用xmldb保存 将变的越来越自然.

mvc中sun从jsp到 jstl jsf 都无法彻底的将 m v分离, 而xml xsl css(在未来可能是 xml xsl svg xul) 能彻底的将 m v分离.

数据库是现在商业应用的核心 rdb本身就限制了开发的灵活性 我想做过大量项目的人都知道. jdbc hibernate 都是围绕 rdb展开的 但是开发依然无法摆脱 rdb的束缚. xmldb直接绕开了这些束缚 用最原始办法   提供了超乎想像的灵活性, 这必将改变未来的软件开发方式和商业应用模式.

针对应用系统，你的意思是程序直接操纵xml，那么封装是在那个层次进行或是没有（系统由一堆xml操纵脚本组成）?


什么叫彻底分离，难道能用xsl 操纵xml，就不能用xxx操纵对象图？

xml框架中 根本不考虑 类和封装 直接由pipeline来对xml进行处理. js 用来控制pipeline流程 相当于 mvc 中的 c.

xml框架中 交互 数据绑定 是由cform ajax来完成的. 只需要定义3个xml文件就可以搞定一个复杂的交互. 比jsf简单灵活. xml框架中 v是最干净 最强大的.

xml db能作为olap系统的数据源吗？

没有对应用进行逻辑上的封装挺恐怖的，好比在jsp上分布各种数据库操纵脚本（xml不过在信息描述能力上比resultset强）。

内存对象模型有对象的引用管理能力，xml不具备把？

xml的优势在天生的操纵能力，系统各个层面都有相应的工具给这些能力提供支持。

rdbms确实极大限制了面向对象设计和开发软件系统的能力，不过按照这个逻辑，我与其搞什么xmldb，还不如用OODBMS，一了百了。对象直接进入数据库存储。你xmldb还需要对象转换到xml呢。这完全不构成使用xmldb的理由。

我感觉你对技术有点偏执，一旦钟爱某种技术(LVS,XMLDB)，眼睛里面再也看不到其他东西了，恨不能什么方面都往这种技术上面套。