锁定老帖子 主题:存储过程真的好快!
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
---|---|
作者 | 正文 |
发表时间:2008-05-08
我喜欢存储过程和pro*c,,高性能的运算平台,在业务电信行业的支撑系统,八达通卡积分管理系统,我们的业务流程全是oracle存储过程来写..每个业务都配置好非常详细的Visio流程图,并为每每个业务流程编写有相应的存储过程测试代码..非常的高效能,没有维护不方便的问题,主要还是看项目团队的技术水平
|
|
返回顶楼 | |
发表时间:2008-05-08
每个人的业务背景不同,容易得出不同的结论。 对于电信金融行业,你叫他时不时转数据库,是完全不可能的,存储过程很好很强大。 对于短平快的行业软件产品,你叫他绑定数据库,是会影响这软件的销售的。所以,ORM就显得有必要。 呵,一句话,业务决定技术。 |
|
返回顶楼 | |
发表时间:2008-05-08
ironsabre 写道 ltian 写道 N年前大量的业务逻辑程序就是存储过程干的。除了调试不方便外,用存储过程业务法满足跨数据库的需要,今天A客户用ORacle,明天B客户用sybase。这个问题如何解决?
另外大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计,无法采用面向对象的方式将业务逻辑进行封装,从而无法形成通用的可支持复用的业务逻辑框架。 不过,在对性能影响较大的时候在局部采用一个存储过程也可以的,但是目前几乎很少碰到性能到了用户无法接受情况。 我所见到的有些系统大量采用了存储过程,由于对游标等对象操作不当,导致系统整体性能不佳的情况框也很多。上千行乃至几千行的存储过程在这些系统中比比皆是,最后导致很难维护。 首先,你所说的存储过程调试不方便是不存在的。在用对了工具时,存储过程的调试对于数据库应用来说,比其他语言都更为方便。用一下PL/SQL Developer试一下。 第二:A客户要用Oracle,B客户要用sybase的问题。很好解决,我们只提供Oracle版本的产品。就算是和IBM合作,也没有使用DB2。Oracle就是比其他数据库好,没有办法。当然Oracle也是最贵的,但是对于大型项目来说,我们的客户不会在乎数据库的价格。这是他必须要付出的。 第三:关于存储过程维护难的问题,更是可笑。我们的核心计算几乎全部是PL/SQL写出来的。经常会有写得极好的成千上万行的PL/SQL存在。而对于Java来说,我觉得面像对象的东西,很多个Class写在那儿,可真正专注于计算的,也就是几行。大多数Java没有在计算,但Java可以用来搭出很好的架子来。我们公司的做法就是Java搭架子 + PL/SQL的核心计算。极好。关于这个做法,就我所知,在真正需要强大计算的金融保险行业极为流行。这是实践出来的东西。 也许那些只是简单的CRUD的应用,才会觉得PL/SQL没什么用。 这位哥们,能否说一下你们现在的做法,和你所说的架子是怎样搭建的?普通的MVC模式? 我现在手头上也有一个项目,是维护性的,03年的项目了,只是普通的MVC+ORACLE,所有业务逻辑全部用PL/SQL来写,因为规范得很好,所以维护起来没有什么问题。只是对于新进的开发人员,培训时间较长,因为需要让他们了解很多的表关系。而表却非常多,数百个,非常的苦闷。 |
|
返回顶楼 | |
发表时间:2008-05-09
魔力猫咪 写道 后头有你叫的时候。大量业务写入存储过程,对调试和修改均极为不方便。我觉得你这种业务用缓存的方式解决最好。处理一次,缓存起来。没了查询数据库,不是更快。等缓存失效了,才需要二次运算。缓存时限可以根据你的需求定,哪怕有1分钟,对高并发的访问都是可以大大缓解的。
无比多的大型应用都有SP,银行的更多。 对于简单的CURD,自然不需要SP。但是日常业务除了CURD外,还牵涉到大料的报表操作,银行来说,日报,旬报,月报,季度报,年报,这些跨多表查询汇总的东西,自然轮到SP大显身手。 |
|
返回顶楼 | |
发表时间:2008-05-09
事实上,在OO流行或者ORM流行之前,SP是最可移植,可扩展的方法。我在OO的早期,一般都是把一个业务方法封装到一个存储过程中去的。
现在除了OLAP没啥好说的,OLTP中,如果数据量比较大的情况,除了数据库任务相当繁重的操作,业务逻辑建议用纯OO程序实现(一般业务逻辑只是影响少量记录),结转,报表,统计等等还是建议用存储过程。 |
|
返回顶楼 | |
发表时间:2008-05-10
关键要看自己的团队的知识层次如何, 还要看看将来的应用环境是什么?
如果你的团队都倾向数据库端,数据库技能强, 那么如果你一个人去偏向JAVA, 这个恐怕团队都没法领导。 反之亦然 。 如果你面对的是遗留系统或者海量的数据, 那么把业务逻辑都放的JAVA里肯定不妥 因为我们知道内因才是决定事物的根本因素,有些问题还真得从数据库内部来解决。 当然如果用JAVA等相关的技术是比方便的,那就要大胆的用, 一句话,要计算好投入产出比! |
|
返回顶楼 | |
发表时间:2008-05-12
potian 写道 事实上,在OO流行或者ORM流行之前,SP是最可移植,可扩展的方法。我在OO的早期,一般都是把一个业务方法封装到一个存储过程中去的。
现在除了OLAP没啥好说的,OLTP中,如果数据量比较大的情况,除了数据库任务相当繁重的操作,业务逻辑建议用纯OO程序实现(一般业务逻辑只是影响少量记录),结转,报表,统计等等还是建议用存储过程。 嗯,和我们的方式基本一致。 |
|
返回顶楼 | |
发表时间:2008-05-13
Joo 写道 速度不是企业应用的唯一且最要紧的诉求
我不知道还有什么? 如果你公司叫google,你会说钱不是问题,为了提高性能,你花很多钱 但是你公司非google,你会说问题是没钱,为了省钱,你接受很低性能 |
|
返回顶楼 | |
发表时间:2008-05-20
非常支持“业务决定技术”这个观点。
我现在是在做供应链系统,大量的报表,大量的数据统计,这部分用存储过程。 对于数据的维护,业务逻辑,用前台程序实现最好了。 对于javaEye这样的数据维护和展示型程序,用存储过程干不了什么事情,反而会增加复杂度。 |
|
返回顶楼 | |
发表时间:2008-05-27
存储过程维护起来真的很痛苦!
|
|
返回顶楼 | |