论坛首页 综合技术论坛

存储过程真的好快!

浏览 36317 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
作者 正文
   发表时间:2008-05-07  
java写的逻辑 最后不是到数据里执行的么?
0 请登录后投票
   发表时间:2008-05-07  
mcpssx 写道
魔力猫咪 写道
几天没见。居然这么大的反应。看到自己的话被大家反复打压,心里真不是滋味。在下也写过一些存储过程。说真的,很难调。也许是我数据库水平太差加不会用开发工具吧,根本不能做什么单元测试、集成测试之类的。只能自己准备测试数据,跑程序,中间自己加print语句输出看是否执行到那里。出的错误也很难搞清楚是哪里的问题。
不过无论如何,我也不会同意Java在处理业务上不如SQL。现在的设计发展趋势均是以对象和领域模型为核心,数据库的关系模型已经退居二线。在表示复杂模型上,ER图很难表示出来。就是表示出来了,理解起来也很费劲。
当然,如果你对象设计功底不到,就觉得存储过程比对象好了。


其实你说反了,大部分时候都是写ORM在打压写存储过程。
java处理业务肯定不如SQL,PL/SQL可以一句顶一万句,JAVA里面好多都是废话,比如jdbc里面的什么准备statment啊之类的。

所谓以对象和领域模型为核心,更是扯淡,纯粹是java的忽悠。

sun不是数据库开发商,所以从一开始就竭力鼓吹把设计都转移到它的java对象上来,所以搞出什么entity bean之类东西。


同意你的观点,其实sql就是 数据领域的dsl语言嘛,要好好掌握,指望orm是不行的。
plsql developer开发调试存储过程完全没有问题,pl/sql也有unit test包
数据库的关系模型退居二线啦?这个真是初次听说
0 请登录后投票
   发表时间:2008-05-07  
我现在就比较头痛,接收的项目里面有块重要的业务逻辑的是用存储过程写的,现在改点东西,都得找DBA改,然后再联调
0 请登录后投票
   发表时间:2008-05-07  
暂且不谈开发效率、维护性的问题,业务逻辑用存储过程来实现最大的危害在于,你没有办法进行群集扩展!

金融和电信行业的确在数据库服务器的硬件投资少不会吝惜,但是数据库服务器是单点的,极难扩展,即便Oracle的群集,他的共享存储数据库也是单点的,如果业务逻辑的运算非常消耗CPU和IO,你没有任何有效的办法来扩展系统的性能。

对于并非极度依赖数据的业务逻辑运算,如果在应用服务器端来实现的话,特别是采用SNA架构的情况下,理论上可以获得无限的水平扩展能力,只要加服务器就行了。但如果你放在数据库里面,你就大眼瞪小眼了,加服务器都不管用了。

对于那些对于性能要求极度苛刻的大负载应用,比方说阿里巴巴,拥有中国最强的Oracle DBA团队,已经把Oracle的配置优化到极限,已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程,甚至不允许程序员创建触发器、不允许程序员创建表的外键约束,外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层,加重数据库服务器的负担。

我只希望大家记住一点:数据库服务器出现CPU和IO瓶颈,你没有办法扩展,但是应用服务器出现CPU和IO瓶颈,你只需要加服务器就行了。



2 请登录后投票
   发表时间:2008-05-07  
从来就没有见过一句顶1W句的SQL。倒是Hibernate让我们省了很多表到对象的转换语句。
你把业务都写死在数据库上了。如果业务中途要调用远程查询一些数据呢?你做DBLink访问人家数据库?人家数据库不许你这么访问怎么办?对方没有数据库只有Web Service呢?存储过程基本上就只能和自己及可以提供和自己链接的数据库打交道。这样能适应需求吗!!!
现在需求分析、领域建模,都是以UML的用例、类来分析。用ER图分析需求,你看现在哪本教开发的书还这么写?
开发现在讲究敏捷、随需应变。可以快速组合业务流程。你存储过程能做到吗?
现在开发初期需求不明确,造成数据结构反复变动。你数据库每变一次,存储过程都要重写。Java只需要改改对象,框架会自动修改对应的数据库结构。
0 请登录后投票
   发表时间:2008-05-07  
留恋存储过程的,我想大多数人可能是最近几年都脱离了实际的开发的人。记得当初某人曾说,用存储过程吧,反正这个业务10年也不会发生变化。而且我还不是在一个人那里听到的这个说。但是这些系统仅仅过了三年就要升级,因为业务规模和企业需求的发展大大超乎当初的设想。
不要以为一种技术理论开始流行仅仅是人们的炒作。把业务分层,与数据和显示、硬件隔离的思想,已经出现了20年了。可以说分层的思想一出现,人们就在说这个问题。而且一直对这个问题的看法如此一致。这些都是建立在大量的大规模企业应用的基础上得到的血的教训带来的。
可以说即便硬件的更新再快,也赶不上需求的要求。CPU和IO瓶颈,昨天是,今天是,明天依旧是问题。而一旦需求来了,不会有时间给你去解决这个问题。这个时候最简单的方式,就是直接加点应用服务器。这个方法比任何方法都见效快,而且往往也最便宜。
0 请登录后投票
   发表时间:2008-05-07  
robbin 写道
暂且不谈开发效率、维护性的问题,业务逻辑用存储过程来实现最大的危害在于,你没有办法进行群集扩展!

金融和电信行业的确在数据库服务器的硬件投资少不会吝惜,但是数据库服务器是单点的,极难扩展,即便Oracle的群集,他的共享存储数据库也是单点的,如果业务逻辑的运算非常消耗CPU和IO,你没有任何有效的办法来扩展系统的性能。

对于并非极度依赖数据的业务逻辑运算,如果在应用服务器端来实现的话,特别是采用SNA架构的情况下,理论上可以获得无限的水平扩展能力,只要加服务器就行了。但如果你放在数据库里面,你就大眼瞪小眼了,加服务器都不管用了。

对于那些对于性能要求极度苛刻的大负载应用,比方说阿里巴巴,拥有中国最强的Oracle DBA团队,已经把Oracle的配置优化到极限,已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程,甚至不允许程序员创建触发器、不允许程序员创建表的外键约束,外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层,加重数据库服务器的负担。

我只希望大家记住一点:数据库服务器出现CPU和IO瓶颈,你没有办法扩展,但是应用服务器出现CPU和IO瓶颈,你只需要加服务器就行了。





有点疑惑,如果把大量的业务逻辑放到webserver来处理,那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理,然后dbserver只返回少量处理后的数据多。
当访问量大规模提高之后,webserver和dbserver这种传输的消耗肯定也要大规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的?
0 请登录后投票
   发表时间:2008-05-07  


我只希望大家记住一点:数据库服务器出现CPU和IO瓶颈,你没有办法扩展,但是应用服务器出现CPU和IO瓶颈,你只需要加服务器就行了。



   有个问题。如果中间件服务器扩展到10台,假设同时10台机器上同时需要计算大量业务运算,而这些运算最终还是要到数据库上运算的到时一样会有IO瓶颈的。

    企业应用系统的集群,我认为主要是解决高可用性,很多业务是7×24的,所以用群集的。

业务逻辑用存储过程来实现最大的危害在于,你没有办法进行群集扩展!没明白这个和业务逻辑用存储过程有什么关系。
0 请登录后投票
   发表时间:2008-05-07  
ygxdha 写道
robbin 写道
暂且不谈开发效率、维护性的问题,业务逻辑用存储过程来实现最大的危害在于,你没有办法进行群集扩展!

金融和电信行业的确在数据库服务器的硬件投资少不会吝惜,但是数据库服务器是单点的,极难扩展,即便Oracle的群集,他的共享存储数据库也是单点的,如果业务逻辑的运算非常消耗CPU和IO,你没有任何有效的办法来扩展系统的性能。

对于并非极度依赖数据的业务逻辑运算,如果在应用服务器端来实现的话,特别是采用SNA架构的情况下,理论上可以获得无限的水平扩展能力,只要加服务器就行了。但如果你放在数据库里面,你就大眼瞪小眼了,加服务器都不管用了。

对于那些对于性能要求极度苛刻的大负载应用,比方说阿里巴巴,拥有中国最强的Oracle DBA团队,已经把Oracle的配置优化到极限,已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程,甚至不允许程序员创建触发器、不允许程序员创建表的外键约束,外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层,加重数据库服务器的负担。

我只希望大家记住一点:数据库服务器出现CPU和IO瓶颈,你没有办法扩展,但是应用服务器出现CPU和IO瓶颈,你只需要加服务器就行了。





有点疑惑,如果把大量的业务逻辑放到webserver来处理,那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理,然后dbserver只返回少量处理后的数据多。
当访问量大规模提高之后,webserver和dbserver这种传输的消耗肯定也要打规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的?


在这个自然界中,所有的线性关系(假定是Y = K × X)都是对实际的非线性关系的模拟,
在一定的误差范围内,是存在适用范围的
一旦X超出这个范围的边界值,线性预期值(Y)与实际值的偏差就会大到不容忽视的地步,
这个偏差通常会反过来削弱被期待的效应(Y),类似于一个负反馈系统
于是,被期待的效应(Y)就会随着X的增大而趋近一个极限值

经济学上的“边际效应递减”,说的是类似的意思

比方说:在只有一台server的时候,再增加一台server,性能的提高是明显的,接近K ×(1+1)
但随着server越来越多,效果就会越来越不明显,甚至于发生恶化


在软件工程的领域,一定的条件下,增加人员可以缩短开发时间
但是,这并不意味着增加N倍的人员就可以使开发时间缩短到原来的1/(N+1)
所以,没有银弹
0 请登录后投票
   发表时间:2008-05-07  
莫生气 写道
我现在就比较头痛,接收的项目里面有块重要的业务逻辑的是用存储过程写的,现在改点东西,都得找DBA改,然后再联调


完全听不懂你在说什么。DBA来给你改存储过程?
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics