设想使用XML和关系数据库形成一个对象数据库

原文：http://zwwwxy.blogchina.com/blog/article_81038.1423950.html

 今天的数据处理方式呈现出明显的在表达层和数据层中间加入了一个中间件层，一方面以OR映射的方式把关系数据库中的结构化数据映射成内存中的对象；另一方面表达层可以直接访问这些对象提取所需要的属性。对象数据库从十年前开始出现，目的是为了满足这一访问向中间层转变的需要，甚至设想把对象直接串行化存入数据库中，从而加快数据处理的效率（如ORACLE）。但由于在这个处理过程中弱化了对象间的相互关系，反而使得数据冗余超出了实际可以承受的范围而得不到广泛的认可。

    对于子公司/科室机制，由于每一个子公司都要求是一个可独立管理，由组角色向用户分配用户的单位容器，涉及到的复杂对象，主要是子属性集合，如服务、频道、专栏等等，也比较地多，如果使用传统的关系数据库-》对象映射机制的话，本身就是一个相当大的工程。把它使用xml实现，是利用于xml的对象化组织功能和digester自动填充对象属性的能力，从而降低了底层开发的难道。但随着参与的子公司/科室变得越来越多，内存的占用也变得越来越大，这样就产生了向更永久性的关系数据库转移存储量的要求。但是，关系数据库本身的非对象化特性导致它必须有一个OR层才实现把数据库中的行记录转为内存中对象池中的可访问对象，这就令转移中产生了一个悖论：要么否定XML的对象存储的价值观念，要么不用关系数据库。而避免悖论的产生的唯一途径，看来就是组织出一个关系对象数据库。

    (关系)对象数据库早在十年前就出现了，ORACLE也很早就可以提供统一OID索引的对象表，并提供SQLJ对象转换层。不过对象数据库在十年后都没有成为数据层设计的主要解决方案，其中必有其原因。在我看来，对象数据库与关系数据库最大的区别在于对外键的管理。外键是关系数据库的特有概念，它是对不存在本实体（表）的外部基表的键作为子表（list)对象的索引，要得到一个基表的子类型，最标准的办法就是遍历该表的外键，看看是否符合基表的ID。对象数据库的出现就是针对这种低效的多次遍历（表现为关系数据库的多表连接），使用引用集合作为外键属性的处理方式。换言之，在对象数据库中，外键是没有意义的，对象在自已的命名空间内保留基子对象的集合，直接通过集合定位自已的子对象的位置，而不是通过遍历外部集合与本ID匹配。显然，这样效率要高得多；但是如何处理本身的集合问题就大成问题了，尽管各个数据库分别开发了自已的集合类型，但都没能成为SQL的标准规范，也不能提供一致性的象SQL那样的简洁高效的查询语言。大概，这就是对象数据库仍没有普及的一个原因。

XML作为一个自动管理对象的容器，有可能扮演解决这个"查询和对象自动转化"角色。我的设想是在表中提供一个字段，以XML形式存储该对象的相关子属性的集合，在使用时把这个字段作为字节流交给digester但自动解释工具获得对其子集合的解释。对象实现dao接口，这样如果需要就通过DAO从数据库中读取对象属性。这样，就解决了上面的所有矛盾；而没有增加什么特别的编码量。当然，作为对这种机制的支持，一个基本的扩展并结合 jakarta.digester/dao的管理层是必须开发出来的。与直接的XML存储方式相比，这个机制必须提供一个编辑属性的工具，要抵消存入数据库后不能编辑XML的缺陷。达到这一步后，应该比传统的关系ER设计再映射为内存对象的方式，无论是使用EJB，JDO，还是Hibernate, Liberante,Hanva这类OR映射的方式，效率都要高，省掉了两步工作，并且可以直接把XML作为不同平台的交换层。同时，也省却了关系映射中最麻烦低效的多表连接。

设想还找不出明显的破绽，实现的难度也不算高；完成这个功能大致需要几天的时间，稍后可以把它做出来。