掷鸡蛋者
发表于: 2010/7/8 9:44 引用 回复 只看该作者 1# TOP
管理员
性别: 男
积分:52173
阅读权限:43385
帖子: 8318
加入时间: 2010/4/29
最后登录: 2019/10/8
这是昨天的一个回帖,觉得可能其他人会感兴趣,就作为主题帖子再重复发一下

我们来看ORM和存储过程,会发现——

1)理念的区别

从sql或存储过程开始设计的开发,是面向关系型数据库的,后来面向对象开发兴起,人们发现面向数据库和面向对象思维方面不太一致,匹配有障碍。就出现了ORM,希望以面向对象化的思维设计程序,然后通过这个ORM工具,映射到关系数据库中。

ORM的目的,就是先设计对象,然后再映射到关系数据库,终极目标就是希望软件开发的过程,完全以面向对象的方式来设计。一个完美的ORM,即使开发者完全不会数据库也可以使用。当然,终极目标和完美境界,都是不存在的。

2)实际的作用

ORM在实际开发中带来的帮助,我觉得主要还不是面向对象的设计方式的变革,而是它作为一个引入的中间层,带来了额外的好处:
a)大多数数据库操作都更加方便简单了(许多人都离不开ORM,就是因为极度的方便)
b)更不容易犯数据库操作中的一些低级错误,比如重复的sql查询、比如大量的注入攻击漏洞等等
c)屏蔽了数据库的差别,可以支持多种数据库
……

而在实际开发中,缺点也很明显,就是关系数据库最擅长的复杂查询,ORM明显力不从心,不仅仅是wojilu ORM,凡是有经验的ORM使用者,比如hibernate方面的开发人员,一般也不会用ORM做复杂的查询。

关于存储过程,特别谈一下我的看法。

如果关注过微软出的一些示例程序,发现都是把复杂的业务逻辑放在存储过程中,中间层只要简单调用一下这个存储过程就可以了,代码看起来非常清爽整洁。但许多人认为(包括我),它有几个缺点:

a)过于依赖数据库,甚至可以说,这种开发方式,基本上在微软的特定数据库上绑定死了。也可以说,这种开发方式的出发点,很大程度上是有利于微软的商业利益的。

b)存储过程不利于维护和业务逻辑的复用、分解和重构。你是数据库高手,也许不觉得什么,但对于水平不等的其他程序员,维护或调试修改其他人的存储过程,往往是一场灾难。

c)虽然存储过程的重要优点,是提高性能,但在实际场景中的后果却是阻碍了性能。具体讲,相对于sql,存储过程虽然有那么一些性能优势,但因为绑定死了特定数据库,反而不利于数据库的垂直分区和水平分区。同时,海量数据下,大量使用nosql数据库(非关系型数据库)等其他方式的存储,已经是必经之路,存储过程成了这方面巨大的障碍。

最后,我觉得ORM应该是一个必备工具,但它不能代替原生的数据库操作,在复杂的查询需求下,sql或存储过程还是很有必要的。我觉得以ORM为主,辅之以sql或存储过程,是比较实用的策略。

不当之处,欢迎讨论。(原帖在这里:http://www.wojilu.com/Forum1/Post/2131 )


关键词 存储过程 修改tag
而死,不默而生
Dabao
发表于: 2011/6/26 13:58 引用 回复 只看该作者 2# TOP
江湖新秀
性别: 男
积分:100
阅读权限:15
帖子: 1
加入时间: 2011/6/26
最后登录: 2011/6/26
认同你的观点
newSofts
发表于: 2011/6/26 14:02 引用 回复 只看该作者 3# TOP
版主
性别: 男
积分:2482
阅读权限:1605
帖子: 283
加入时间: 2011/6/12
最后登录: 2013/10/16
掷鸡蛋者
发表于: 2011/6/26 15:44 引用 回复 只看该作者 4# TOP
管理员
性别: 男
积分:52173
阅读权限:43385
帖子: 8318
加入时间: 2010/4/29
最后登录: 2019/10/8
认同你的观点
Dabao at 2011-6-26 13:58

旧帖被顶,多谢。

欢迎交流。

而死,不默而生
掷鸡蛋者
发表于: 2011/6/26 15:44 引用 回复 只看该作者 5# TOP
管理员
性别: 男
积分:52173
阅读权限:43385
帖子: 8318
加入时间: 2010/4/29
最后登录: 2019/10/8
newSofts at 2011-6-26 14:02

 欢迎分享技术

而死,不默而生
onedot
发表于: 2011/7/30 1:23 引用 回复 只看该作者 6# TOP
江湖少侠
性别: 男
积分:492
阅读权限:205
帖子: 34
加入时间: 2011/7/29
最后登录: 2011/9/19
对观点部分赞同

SP其实很多时候还是为了方便解决复杂的商业逻辑的,尤其是需要原子操作的场合

且不论SP有编译过的执行性能提高,单是复杂商业逻辑需要用开发代码实现的话,会大大增加与DB得交互次数就足够拉低效率了

而数据库切分其实和SP是没有关系的,因为SP肯定是要做到每个DB都存在的

主要还是要看应用场合,真的海量数据真的是相对简单的数据处理逻辑的话没有必要了




TianyinCms
发表于: 2011/8/23 14:18 引用 回复 只看该作者 7# TOP
江湖新秀
性别: 男
积分:211
阅读权限:100
帖子: 15
加入时间: 2011/8/16
最后登录: 2011/8/24
那么海量数据是不适合用ORM了?
mahua
发表于: 2012/1/7 18:52 引用 回复 只看该作者 8# TOP
江湖新秀
性别: 男
积分:129
阅读权限:55
帖子: 8
加入时间: 2012/1/5
最后登录: 2012/2/23
我认同使用orm可以带来便利,但存储过程是不可替代的,因为orm不能解决所有的问题,尤其是海量数据,或者复杂业务的时候,orm写起来太累的,这个我深有体会的。table1.add,table2.update,....tablen.delete这样的复杂逻辑放到一起的时候,使用orm就很尴尬了
掷鸡蛋者
发表于: 2012/1/7 19:30 引用 回复 只看该作者 9# TOP
管理员
性别: 男
积分:52173
阅读权限:43385
帖子: 8318
加入时间: 2010/4/29
最后登录: 2019/10/8
我认同使用orm可以带来便利,但存储过程是不可替代的,因为orm不能解决所有的问题,尤其是海量数据,或者复杂业务的时候,orm写起来太累的,这个我深有体会的。table1.add,table2.update,....tablen.delete这样的复杂逻辑放到一起的时候,使用orm就很尴尬了
mahua at 2012-1-7 18:52

 嗯,不矛盾,我文中也是这个意思

而死,不默而生
zhaoy
发表于: 2012/1/9 17:37 引用 回复 只看该作者 10# TOP
江湖新秀
性别: 男
积分:155
阅读权限:92
帖子: 18
加入时间: 2011/10/27
最后登录: 2013/10/21
同意楼主,巨型存储过程的维护确实是一件让人头疼的事,特别是存储过程层层嵌套的情况下。

快速回复主题