|
锁定老帖子 主题：探讨用存储过程的优劣
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-25
glovebx 写道 houxinyou 写道 感觉楼主的系统是用了N久之前的框架,除了做页面基本不用改什么,把存储过程在配置文件中一设置就OK的那种.项目的环境也很确定,不是互联网应用,最多几百个客户端,并发也不是很多.项目不论怎么发展,客户端也基本是固定,无非就是加一个模块,增加点功能.而且说的不好听一点,很有可能是那种一锤子买卖,项目验收后基本上就啥也不管了.维护的事给钱都不一定管的不管的那种!这样的程序,界面漂亮一点,业务端和数据库只要有一处做的稍好一些就不会出性能问题.也不可能发展到楼上各位所说的那种还需要集群的程度.能把程序和数据库分到两台电脑上都是相当不错的了,多数情况下都是在一台电脑上.
我解释一下。 1、系统不是N久之前的框架，一直以来我们用的是以Spring+struts为底层扩展而来的框架，一点都不用存储过程。 2、项目环境确定，因为从技术选型到服务器安装调试一条龙都是我们决定的。 3、确实不是面向互联网的应用，所以我们的前端是flex。 4、不是一锤子买卖，是要一直维护下去的项目。项目验收后，一直在做扩展和优化。 5、tomcat和mysql分别部署的，而且还有tokyo cabinet做缓存，两台os都是centos5.5。 严格说起来，这是我们公司的产品，顺应客户的要求做定制化。 我不是很清楚你们的情况,只是说一下我自己的理解. 以我的经验,做这种项目的公司一般都是有自己固定的行业的,所以每一个项目的业务大概是相同的,当然,细节上肯定也是有所不同的.也正是因为这样,所以你们把一些可变的业务逻辑放在存储过程中. 当有下一个项目或者是客户业务需求发生变化时,应用程序部分基本不用修改,只要对存储过程的细节部分做一些修改就可以了. 这样的优点是: 修改起来容易,因为业务每次都不会发生大的变化,细节都在存储过程中,改了存储过程就可以了,不用替换应用程序部分. 这样的缺点是: 1.不利于软件产品化,正常把业务逻辑放在应用程序中时,可能整个单位只维护一套产品(这个产品指的是全部的东西,包括代码和数据库),当然,所有的功能都在这一套产品中,对于不同客户的不同细节,用一些特殊的方法(比如接口,条件等)实现,各种实现只要在配置文件中修改就可以了.而存储过程中虽然也可以做到,但存储过程不太适合放太多的那种根本用不到的业务.所以,大部分都是每个项目要单独维护一套(至少存储过程要每个客户单独维护一份). 2.绑人,如果是产品化的,大家只要了解自己产品就够了(虽然东西会比较多),当一个客户有特殊要求的时候,按开闭原则,加入一部分功能,改配置文件就成了.而每个项目单独维护一份的话,一般的情况是分给某一个人维护某几个项目.而其它人对这个项目不是很了解,一些小活很难参与.而维护项目的人会因有头事比较多,很难参与到其它项目中 以上只是个人见解,说错了请见谅 |
| 返回顶楼 | |
|
发表时间：2011-01-25
最后修改：2011-01-25
lobbychmd 写道 很多人直接在数据库创建 sp，而不是用文件保存起来，就不好用 版本控制系统
天下没有这种神人（不怕老板K，不怕丢饭碗）。从这句话可以推断你大概没真正用过数据库。 |
| 返回顶楼 | |
|
发表时间：2011-01-25
ironsabre 写道 to liuchuan98:
我点名了，请你告诉我为什么sp的版本控制很难搞。你用了很字。 这跟我自己的经验对不上，所以我一定要知道你们在搞什么。为什么会有这个问题出来。 我想知道这里边到底存在什么误解。 我用PL/SQL Developer写存储过程。每次修改过copy出来，上传到SVN，麻烦，而且有时候会忘记。 Java的IDE一般都集成了SVN，方便 |
| 返回顶楼 | |
|
发表时间：2011-01-25
bureaucrat 写道 ironsabre 写道 to liuchuan98:
我点名了，请你告诉我为什么sp的版本控制很难搞。你用了很字。 这跟我自己的经验对不上，所以我一定要知道你们在搞什么。为什么会有这个问题出来。 我想知道这里边到底存在什么误解。 我用PL/SQL Developer写存储过程。每次修改过copy出来，上传到SVN，麻烦，而且有时候会忘记。 Java的IDE一般都集成了SVN，方便 你可以用Eclipse来管理sp的啊，你在java项目下建一个pl/sql目录，sp代码都存到那儿去，然后你用Eclipse来管理的你sp代码check out checkin不就行了啊。难道你们不是这样做？ 我真的觉得你们好奇怪噢。。 |
| 返回顶楼 | |
|
发表时间：2011-01-25
最后修改：2011-01-25
xiaoshan5634 写道 同意楼上的观点，存储过程对于大量数据的处理能力是非常强的。
真正使用过存储过程的人应该很清楚。 但是存储过程也会带来一个很大的问题----数据库瓶颈，这点也是使用存储过程必须考虑的一个问题。 存储过程能消耗你大量的cpu资源和内存资源，而且写的不好的存储过程会长时间占用连接，长时间等待某些资源而锁定其他的资源，从而很容易造成系统阻塞。所以存储过程尽量写的简短，少用临时表。 有些事情是不管你用什么语言写都会遇到的问题，我不明白为什么会向语言上靠。 比如“长时间占用连接，长时间等待某些资源而锁定其他的资源”这些，你用jdbc还不是一样？ 这跟你的设计有关，跟用什么语言实现是无关的。 |
| 返回顶楼 | |
|
发表时间：2011-01-25
最后修改：2011-01-25
ironsabre 写道 bureaucrat 写道 我用PL/SQL Developer写存储过程。每次修改过copy出来，上传到SVN，麻烦，而且有时候会忘记。 Java的IDE一般都集成了SVN，方便 你可以用Eclipse来管理sp的啊，你在java项目下建一个pl/sql目录，sp代码都存到那儿去，然后你用Eclipse来管理的你sp代码check out checkin不就行了啊。难道你们不是这样做？ 我真的觉得你们好奇怪噢。。 然后咧，怎么调试呢? 请问 
|
| 返回顶楼 | |
|
发表时间：2011-01-25
ray_linn 写道 lobbychmd 写道 很多人直接在数据库创建 sp，而不是用文件保存起来，就不好用 版本控制系统
天下没有这种神人（不怕老板K，不怕丢饭碗）。从这句话可以推断你大概没真正用过数据库。 代码不存下来已经很神了，但据此再推导出存储过程使用版本控制是“很”困难的。这就更神了。 |
| 返回顶楼 | |
|
发表时间：2011-01-25
没看明白lz想讨论什么问题。既然觉得自己的方案很好，那就坚持做呗，还在这里讨论啥？
|
| 返回顶楼 | |
|
发表时间：2011-01-25
最后修改：2011-01-25
flyaswish 写道 没看明白lz想讨论什么问题。既然觉得自己的方案很好，那就坚持做呗，还在这里讨论啥？
+1 我看过很多类似的帖子 一开始，往往是已经确定了的事，拿出来讨论 然后某个不客气的回帖往往会把帖子变成吵架帖 最后甲乙双方更加坚定自己的观点... |
| 返回顶楼 | |
|
发表时间：2011-01-25
wn_1985 写道 flyaswish 写道 没看明白lz想讨论什么问题。既然觉得自己的方案很好，那就坚持做呗，还在这里讨论啥？
+1 我看过很多类似的帖子 一开始，往往是已经确定了的事，拿出来讨论 然后某个不客气的回帖往往会把帖子变成吵架帖 最后甲乙双方更加坚定自己的观点... 好的讨论可以把事情搞清楚吧。 比如一些反sp的人他们的观点根本就不成立，通过这个讨论我想他们应该能改变他们的一些错误观点。 |
| 返回顶楼 | |
