只显示主题贴

问题都没定位好问题,就开始张罗着换数据库。这样做对客户很不负责任。
  • 进入论坛 Java
偷听女孩心 写道pl sql是有异常的概念的。。。给你个链接去学习一下吧。。。外企的老大。。。 http://www.blogjava.net/pdw2009/archive/2006/09/19/70595.html 没人说没有,谢谢。
potian 写道事实上,在OO流行或者ORM流行之前,SP是最可移植,可扩展的方法。我在OO的早期,一般都是把一个业务方法封装到一个存储过程中去的。 现在除了OLAP没啥好说的,OLTP中,如果数据量比较大的情况,除了数据库任务相当繁重的操作,业务逻辑建议用纯OO程序实现(一般业务逻辑只是影响少量记录),结转,报表,统计等等还是建议用存储过程。 嗯,和我们的方式基本一致。
robbin 写道phlsbg 写道我只希望大家记住一点:数据库服务器出现CPU和IO瓶颈,你没有办法扩展,但是应用服务器出现CPU和IO瓶颈,你只需要加服务器就行了。 robbin 你能给出一个具体的数字么?究竟提高到什么程度? 当然JavaEye这类网站这类的应用,我是同意的观点。 我想这个帖子是在业务系统为主的前提下 比方说我2005年给X行咨询的一个关于全行票据交易的项目,很繁重的业务运算,一开始跑的还挺快,但上了十几个省的分行以后,一个WebSphere顶不住了,繁忙的时候页面响应很慢,几乎出不来了。于是我们做了水平和垂直群集,两台HP9000的小型机跑应用 ...
robbin 写道暂且不谈开发效率、维护性的问题,业务逻辑用存储过程来实现最大的危害在于,你没有办法进行群集扩展! 金融和电信行业的确在数据库服务器的硬件投资少不会吝惜,但是数据库服务器是单点的,极难扩展,即便Oracle的群集,他的共享存储数据库也是单点的,如果业务逻辑的运算非常消耗CPU和IO,你没有任何有效的办法来扩展系统的性能。 对于并非极度依赖数据的业务逻辑运算,如果在应用服务器端来实现的话,特别是采用SNA架构的情况下,理论上可以获得无限的水平扩展能力,只要加服务器就行了。但如果你放在数据库里面,你就大眼瞪小眼了,加服务器都不管用了。 对于那些对于性能要求极度苛刻的大负载应用 ...
莫生气 写道 我现在就比较头痛,接收的项目里面有块重要的业务逻辑的是用存储过程写的,现在改点东西,都得找DBA改,然后再联调 完全听不懂你在说什么。DBA来给你改存储过程?
ltian 写道ironsabre 写道ltian 写道NetBus 写道魔力猫咪 写道后头有你叫的时候。大量业务写入存储过程,对调试和修改均极为不方便。我觉得你这种业务用缓存的方式解决最好。处理一次,缓存起来。没了查询数据库,不是更快。等缓存失效了,才需要二次运算。缓存时限可以根据你的需求定,哪怕有1分钟,对高并发的访问都是可以大大缓解的。 恰恰相反,对修改特别方便!特别是以后部署后想修改。 调试成本跟jdbc 直接调用sql没区别。 怎么给存储过程打断点呢? 你认为有实质性的障碍会导致存储过程不能打断点吗? 这个根本不是存储过程的问题,是开发工具的问题。 PL/SQL De ...
ltian 写道NetBus 写道魔力猫咪 写道后头有你叫的时候。大量业务写入存储过程,对调试和修改均极为不方便。我觉得你这种业务用缓存的方式解决最好。处理一次,缓存起来。没了查询数据库,不是更快。等缓存失效了,才需要二次运算。缓存时限可以根据你的需求定,哪怕有1分钟,对高并发的访问都是可以大大缓解的。 恰恰相反,对修改特别方便!特别是以后部署后想修改。 调试成本跟jdbc 直接调用sql没区别。 怎么给存储过程打断点呢? 你认为有实质性的障碍会导致存储过程不能打断点吗? 这个根本不是存储过程的问题,是开发工具的问题。 PL/SQL Developer试用一下。谢谢。
ltian 写道N年前大量的业务逻辑程序就是存储过程干的。除了调试不方便外,用存储过程业务法满足跨数据库的需要,今天A客户用ORacle,明天B客户用sybase。这个问题如何解决? 另外大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计,无法采用面向对象的方式将业务逻辑进行封装,从而无法形成通用的可支持复用的业务逻辑框架。 不过,在对性能影响较大的时候在局部采用一个存储过程也可以的,但是目前几乎很少碰到性能到了用户无法接受情况。 我所见到的有些系统大量采用了存储过程,由于对游标等对象操作不当,导致系统整体性能不佳的情况框也很多。上千行乃至几千行的存储过程在这些系统 ...
小货T61,有什么不敢买的?又不是不保修。坏了商家会给你回香港保的。没那么容易坏。
ironsabre
搜索本博客
博客分类
最近加入圈子
最新评论
评论排行榜