由于厌烦了手写Sql,在几个小项目中尝试着使用了Db4O.DAL层写起来是爽了,但是,还是有很多其它东西会绊你的脚。
- 没有主键的概念(因为对象的内存地址,或者引用就能标志一个对象了).因而外界想指向一个具体的对象就比较困难(比如本页的url里的1079505).
- 激活/保存层次的问题.获取一个对象,它的字段引用了其它对象,那么到底激活多少层次合适?保存时也是如此.层次深了伤性能,层次浅了用着不方便(动不动就是Null reference).
- 对象引用问题.RDBMS里我们能很轻易地明白一个引用指向的是对象的浅拷贝(因为只引用了一个主键).而一旦与内存中的对象勾搭起来,那深拷贝和浅拷贝就不容易区分了,很难说清我删除了一个对象会不会让某个其它对象的某个字段变成null(同样,修改对象也不容易看清其影响范围).
- 对象生存期问题.这是个看起来很奇怪甚至愚蠢的问题:没有被其它对象引用的对象是否应该存在于数据库中?换句话说,ODBMS要不要拥有GC功能?如果有GC功能的话,能够避免误删除被其它对象引用的对象,而且能够清除不再需要的数据.但是相应地,它让开发必须考虑更多的问题,保证每个对象的静态可达性.
- 数据库版本进化难以跟踪.由于数据库的结构与对象的结构基本一致,对对象模型的任何修改都会导致数据库结构的变化,而这个过程中原有数据如何处理必须加以特殊处理(Db4O里提供了字段改名之类的api,但是至少我很讨厌每修改一次对象就要写几行这样的代码).换句话说,我觉得数据库和对象之间耦合严重了,不利于修改.
- 没有类似Sql的成熟且流行的查询语言(或者你必须学习一种新语言)进行数据管理.很多时候,直接操作数据库也是必须的,这时你会非常想念Sql.
总体而言,对于熟悉关系数据库及基于关系数据库进行软件开发的人而言,对象数据库并不仅仅意味着换个存储方式.要真正高效地使用它,可能需要很长时间的摸索和适应.对我而言,Db4O是看起来很美,用起来很玄 :)