对象关系技术的探讨


这是一个很老的问题了,经常在论坛上看到,很多人也写了相关的文章。我在这方面拥有较多的经验,我也谈一下我的看法吧。

我曾经实现过金蝶EAS BOS的多数据支持引擎,脚本引擎,也作过O-R Mapping的预研工作,曾经对多个O-R Mapping产品做过研究。

C++、Java、C#都源自Algol,这系列语言也称为Imperative语言,中文翻译为命令式语言。命令式语言建立在冯*诺依曼体系结构上,程序员必须处理变量管理、变量复制。这样的结果是增加了执行的效率,但带来了程序开发的艰苦。

LISP、Schema、Haskell等语言属于函数式语言,函数式语言基于数学函数,不使用变量或者赋值语句产生结果,使用函数的应用、条件表示和递归作为执行控制。函数式语言是更高级的程序设计语言,和命令式语言相比,编写更少的代码,更高的开发效率,这是函数式语言的明确有点。很多编程技术都首先应用于函数式语言,例如范型、垃圾收集等。很多函数式语言都增加了一些命令式语言的特征,增加效率和易用性。

SQL语言是一个领域专用语言,专门用于处理关系数据。他具备一些函数式语言的特征,在处理关系数据方面非常直观和简介。在处理选择、投影、聚合、排序等等操作方面,显然比在Java或者C#中要方便得多。SQL也是易学易用。很多非程序员都掌握SQL,在金蝶,大多需求人员都熟练掌握SQL。SQL的解释需要损耗一定的性能,在对性能极端要求的情况下,通常不使用关系数据库。例如Google Account采用Berkeley DB等。

现在关系数据库已经发展很成熟,数据库的一些技术发展得很好,包括事务等,其中一些从数据库中发展起来的技术,还应用到操作系统中了。在前些年面向对象技术狂热的时候,作了很多面向对象数据库的研究,但是都没有取得较大的成功。在主流的关系数据库中,大多都包括了面向对象的支持,例如Oracle、Sybase,都具备了很丰富的面向对象功能,但是很少任用。

现在有人跟我说起db4o这样的数据库,我认为db4o不会取得成功,因为他在错误的方向发展。

现在关系数据库最流行,最流行的应用开发语言包括Java、C#等,都是面向对象命令式语言。开发语言需要访问关系数据库,需要转换,转换的过程比较繁琐,于是就诞生了O-R Mapping技术。这是一种妥协的结果,面向对象技术在数据库领域无法取得成功,在面向对象开发语言中,就需要一种对象-关系映射技术。我相信,这种妥协产生的技术,会越来越流行。

我也认为,这是一个正确的选择。就如高级语言不会尝试取代汇编,无论高级语言有多好,最多在其上增加抽象层。例如Java使用bytecode、C#使用IL这样,使用一种抽象层,而不是尝试取代汇编。

O-R Mapping技术除了简单映射之外,需要一种OQL,混合SQL和面向对象特征,提供映射方便的同时,保留关系数据库提供的强大功能。例如聚合、排序等关系运算必须在OQL中提供。由于程序中的返回结果,有时不需要映射成对象,所以OQL必须提供另外一种功能,数据查询。很多O-R Mappping产品都提供了基于对象的OQL和基于数据的OQL。

这导致包括三个部分:
1、应用程序使用OQL
2、O-R Mapping解释或者编译OQL
3、对象数据库负责数据处理

如果O-R Mapping使用解释的方式处理OQL,则会包括产生SQL、组装对象等操作。效率通常都不会很好,现在的O-R Mapping产品基本都是基于解释的方式处理。

如果O-R Mapping使用编译的方式,可以优化产生SQL,动态创建SQL存储过程,减少SQL交互的过程,能够获得很好的性能,可以做到比绝
大多数人直接使用SQL性能都要好。我曾经做过一个实验性的实现,取得很好的效果,可惜由于种种原因,没有继续下去。

我认为,下一代的O-R Mapping产品,都将会采用编译的方式,因为在很多情形下,特别是复杂对象的处理方面,可以有大幅度的性能提升,在某些场景下,可以数倍甚至数十倍的性能提升。

一直不是很看好Hibernate,因为其主要作者gavin对编译技术不了解,2.x版本的HQL语法很搞笑,实现也是很搞笑的,简单的文本替换,看到让人目瞪口呆。3.0之后加入了HQL的AST(抽象语法树),但这不是他本人的做的,其他爱好者加入进来,3.1还是没有很好融合进来。之后的版本我就没有继续关注了。

我觉得O-R Mapping完全就是一种编译技术,不懂编译技术的人去作这件事清总会有些不妥。这不单是Hibernate的问题,也是其他O-R Mapping产品的问题。


我的观点:
1、Java、C#、C++等语言在处理关系数据方面没有优势。SQL是关系数据处理的领域专用语言(DSL),更适合处理关系数据,提供强大的功能。
2、关系数据是主流,希望应用开发人员使用O-R Mapping,而不懂关系数据库,这是不现实的。
3、O-R Mapping技术还有很大发展空间,以后在功能、性能等方面都会有重大提升,最终成熟。

posted on 2007-04-23 08:18 温少 阅读(4573) 评论(8) 编辑 收藏

评论

#1楼  回复 引用   

帅哥你好 看到你的P2P构想及实现 心想你一定是个牛程序员哈 我还是个学生 就像你佩服(你文中提到那个JXTA发起者吧)那人人一样佩服你哈
 我和同学最近也在想用JXTA实现一个跟你一样的目的,聊天和文件共享 本来以为挺简单的,JXTA不是号称提供好多API嘛 简化了P2P应用 结果搞了几周了 感觉还是挺迷茫的 网上又找不到最近的更新的相关文档 郁闷的很 他那些API 都不晓得该怎么用哈 看到你的实现 又觉得挺难的 心想我们是无力为之了 但愿你能提供一点帮助哈 推荐一点最新 的资料或者是提供一点你的实现细节好不好哇 难哪!yanjun_scu@126.com
2007-04-24 09:18 | 枝头鹤[未注册用户]

#2楼  回复 引用 查看   

好奇怪,怎么没人讨论?
我觉得作者的观点深得我心,目前绝大部分OR-Mapping工具、框架确实很搞笑,实现看起来也很诡异。
或许,大家需要的并不是完整的OR-Mapping工具或者框架,大家想要的只不过是访问数据库的直观、简单的方法而已!
2007-04-24 11:29 | 阿齐      

#3楼  回复 引用   

比较现实的做法是 代码生成器。微软一直十一个比较现实注重开发效率的公司,它的在代码中嵌入SQL也是一种可以接受的妥协的做法。

单纯的ORMapping例如TopLink等等的实现,其实让程序员不用SQL,去学习另外一套定义,那么为什么不用心把SQL学好呢?

我们99年就用TopLink, 千万级别的项目,最后系统复杂到很难控制。如果有一套成熟的解决方案,SQL/Oracle早提供出来了。


2007-04-24 14:02 | NoMapping[未注册用户]

#4楼  回复 引用 查看   

业务逻辑写成sql实在是太难看懂了,简直就是脑筋急转弯。于是就把业务逻辑写成对象模型,这样就简单了。
可是对象模型再好,也要往数据库里去保存,于是就有了orm。
开发者需要把对象和数据表的映射关系告诉orm框架,现有的orm框架都是读取这个配置文件来动态的解释o-r映射,如果能够采取编译实现,当然效率更高了。编译后的效率与直接sql写进object里面差不多。
2007-04-26 11:25 | 小陆      

#5楼  回复 引用 查看   

个人认为学好sql是最好的办法!
2007-04-27 12:57 | 宋欢.net      

#6楼  回复 引用   


说得非常好,很可惜之前没有看到这样的文章。

谢谢!

BTW, "可惜由于种种原因,没有继续下去。",太可惜了。
2007-10-16 22:01 | billqian[未注册用户]

#7楼  回复 引用   

--引用--------------------------------------------------
阿齐: 好奇怪,怎么没人讨论?
我觉得作者的观点深得我心,目前绝大部分OR-Mapping工具、框架确实很搞笑,实现看起来也很诡异。
或许,大家需要的并不是完整的OR-Mapping工具或者框架,大家想要的只不过是访问数据库的直观、简单的方法而已!
--------------------------------------------------------


深有同感,就是想不明白为什么还有那么多人用它来做东西。。呵呵。
2008-02-14 14:30 | ken1984[未注册用户]

#8楼  回复 引用   

看来你直指的就是MS的LINQ了。不知道MS实现的合你心意吗?