|
精华帖 (2) :: 良好帖 (2) :: 新手帖 (15) :: 隐藏帖 (5)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-07-31
icewubin 写道 pp21 写道 hu_huter@msn.com 写道 这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。 同意楼上的观点，lz没有对症下药。 存储过程的调优是比较艰辛，需要耐心。 例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。 要说效率为什么现在没多少人用汇编和机器二进制码去做，这个道理大家都懂，某些人不要因为自己sql怎么怎么好就说楼主这样那样不行，我看楼主说的基本都没什么太大的问题。 1.任何一个项目的资源都是有限的，不可能今天需要存储过程高手，公司里就冒出个存储过程高手来编代码，如果他跳槽了，谁来维护，花很少的钱再去找一个，你去招招看。 2.sql作为一种面向过程的dsl语言，在某些方面不如面向对象的语言，很正常么，尤其是在JVM的帮助下，Java当然可以非常高效，楼主都已经说了他们的业务逻辑的特点了，有些人还在强调什么算法，算法是业务逻辑么？ 3.sql和一些特殊的sql语句无非就是对关系数据库的操作和优化操作，但是一旦这些优化的命令和操作对现有的的复杂业务逻辑计算提供不了太多的帮助，计算效率下降，代码量成倍增加，可维护性就会很差，维护人员时间成本（包含工资成本）就非常高。 4.楼主也说了，有些逻辑（其实就是适合用sql来做的）会考虑再次放到存储过程来做，说得很好啊。 5.有一位网友说的也很好，很多时候数据库就是瓶颈，扩展的代价远比扩展应用服务器昂贵和复杂，根本就不应该占用宝贵的数据库资源做业务逻辑操作。 再次说明，存储过程很强大么？怎么不去写操作系统或者是httpserver呢？有多线程么？有分代垃圾回收么？有清晰完整的内存数据存储模型么？ 特定的DSL语言就是做特定的事情。 问题是LZ没有找到性能瓶颈在哪里。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
ironsabre 写道 icewubin 写道 pp21 写道 hu_huter@msn.com 写道 这种事情可能发生吗？ 除非你的存储过程写的很糟糕！
听上去酒店n大才能发生这种情况。假定酒店有1000个房间，每个房间每天产生100条相关数据，写存储过程每天算，估计最多1分钟。 同意楼上的观点，lz没有对症下药。 存储过程的调优是比较艰辛，需要耐心。 例如，在我现在的这个项目，做数据抽取，以前用java代码做抽取，300组记录(包括主表，子表)，这还其中涉及了许多统计，需要20分钟以上，客户天天投诉。后来将全部java代码改成存储过程，并对每个sql语句都进行调优。最后的效果是300组记录的数据抽取，存储过程只要400多毫秒就完成，如果算上其他的损耗，整个过程也不超过2秒。客户对这个结果非常满意。 要说效率为什么现在没多少人用汇编和机器二进制码去做，这个道理大家都懂，某些人不要因为自己sql怎么怎么好就说楼主这样那样不行，我看楼主说的基本都没什么太大的问题。 1.任何一个项目的资源都是有限的，不可能今天需要存储过程高手，公司里就冒出个存储过程高手来编代码，如果他跳槽了，谁来维护，花很少的钱再去找一个，你去招招看。 2.sql作为一种面向过程的dsl语言，在某些方面不如面向对象的语言，很正常么，尤其是在JVM的帮助下，Java当然可以非常高效，楼主都已经说了他们的业务逻辑的特点了，有些人还在强调什么算法，算法是业务逻辑么？ 3.sql和一些特殊的sql语句无非就是对关系数据库的操作和优化操作，但是一旦这些优化的命令和操作对现有的的复杂业务逻辑计算提供不了太多的帮助，计算效率下降，代码量成倍增加，可维护性就会很差，维护人员时间成本（包含工资成本）就非常高。 4.楼主也说了，有些逻辑（其实就是适合用sql来做的）会考虑再次放到存储过程来做，说得很好啊。 5.有一位网友说的也很好，很多时候数据库就是瓶颈，扩展的代价远比扩展应用服务器昂贵和复杂，根本就不应该占用宝贵的数据库资源做业务逻辑操作。 再次说明，存储过程很强大么？怎么不去写操作系统或者是httpserver呢？有多线程么？有分代垃圾回收么？有清晰完整的内存数据存储模型么？ 特定的DSL语言就是做特定的事情。 问题是LZ没有找到性能瓶颈在哪里。 我看你也属于这种，找不到真正问题所在的主。 因为这么明显的贴子你都看不到真正的问题在哪里。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
功底不够！
回去反省 不要再回复了，让这个帖子沉了吧。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
ironsabre 写道 问题是LZ没有找到性能瓶颈在哪里。
我看你也属于这种，找不到真正问题所在的主。 因为这么明显的贴子你都看不到真正的问题在哪里。 别尽说些没用的空话，说点具体的，你说说看问题在哪里，你说如果你用存储你打算怎么做。 你打算如何模拟java的存储模型，如何复用内存数据，如何非常有效的管理缓存数据，如何不影响主业务数据库？ 哦，你肯定会说，“我有必要用这些么，存储很好和强大，效率就是比Java高”，呵呵，我还是那句话，既然效率高，你怎么不去用C或者汇编？你怎么不自己用存储过程写一个类似于ROR的框架来做业务逻辑？ 哦，你肯定又说那是web框架，和我有什么关系，你也知道没关系？ 那好，你无非是觉得没有不能优化的存储过程，只有蹩脚的程序员，既然有人用数据库做了面向报表统计优化的OLAP，你怎么不用存储过程写一个类似于Lucene的搜索引擎，这总不是web框架了吧，而且也是对数据进行处理，你不是说效率远比Java高么？ 你说什么叫“真正的问题”？你认为的就“真正”么？数据库能解决真实世界的所有计算问题了？我觉得你才属于那种问题定义都不清的那种。如果你是这个楼主提到的项目的项目经理，你打算如何决策，对客户说，我亲自出马，重写存储过程，优化算法？还是说我马上去招一个能用存储过程重写这些业务逻辑的人，先让他熟悉业务逻辑，然后在总共2个月完成项目的需求理解、编码、测试、验收？还是说回聘当初那个写这些存储过程的人，让他改写？还是赶快培训这个水平低下的写这个存储过程的人（假设没离职），然他2个月内搞定这件事？还是到JavaEye来高薪聘你去当数据库顾问？ 你好好想想，如果你是这个项目的项目经理，你到底会怎么决策。 哦，还有人说功底不够，那您给个标准，怎么样的功底算够？能用存储过程实现任何业务逻辑？ 哦，好像是有位数据库大师说过类似的话，那您达到那位大师的境界了么？ 那位大师说这话也有些年头了，如果那位大师说的是真理，为什么现在数据库界没有统一世界呢？ 照这位大师逻辑，所有的银行、保险、证券、基金公司新开项目的业务逻辑应该全部用存储过程，前台调用存储过程就全部搞定了，否则就是开发人员功底不够啊。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
你写这么多也只能证明你的思维混乱。
|
| 返回顶楼 | |
|
发表时间：2008-07-31
这个问题根本不在于存储过程，还是用Java，或是别的。
问题是，如果找到了真正的耗时点，都用同样的解决方案。 不管你是存储过程，用Java，还是用任何别的什么东西，耗时是基本差不多的。 可能的结果是：用Java花了三秒，用存储过程2.5秒，也许用C是2秒。 基于数据库的应用的非大用户量的，耗时是基本上不可能出现在语言级的。 再说一次，我想说的问题是，不管你用存储过程还是Java，都不是因为这个让LZ的应用的耗时出现在如此大的变化。 真正的原因是是他在改用Java的时候，改变了一些处理方式，这种处理方式的改变才造成了耗时大大减少。而LZ最大的问题是，他认为这种变化是因为他使用了Java造成的。但这不是事实。 我一直在批评的就是这个。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
照这位大师逻辑，所有的银行、保险、证券、基金公司新开项目的业务逻辑应该全部用存储过程，前台调用存储过程就全部搞定了，否则就是开发人员功底不够啊。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 巧了，我就是做保险核心系统开发的，真正重要的核心逻辑全部都是存储过程。 而且就我所知的同行业主流厂商都是在这么做的。具体的好处在做的人都会明白。 所以你不要想当然。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
你好好想想，如果你是这个项目的项目经理，你到底会怎么决策。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 如果我是这个项目经理，我想我的项目肯定不会需要LZ和你这样的，在问题没有搞清楚之前就开始动手，靠巧合来编程的人。 |
| 返回顶楼 | |
|
发表时间：2008-07-31
ironsabre 写道 照这位大师逻辑，所有的银行、保险、证券、基金公司新开项目的业务逻辑应该全部用存储过程，前台调用存储过程就全部搞定了，否则就是开发人员功底不够啊。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 巧了，我就是做保险核心系统开发的，真正重要的核心逻辑全部都是存储过程。 而且就我所知的同行业主流厂商都是在这么做的。 所以你不要想当然。 |
| 返回顶楼 | |
|
发表时间：2008-08-01
ironsabre 写道 照这位大师逻辑，所有的银行、保险、证券、基金公司新开项目的业务逻辑应该全部用存储过程，前台调用存储过程就全部搞定了，否则就是开发人员功底不够啊。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 巧了，我就是做保险核心系统开发的，真正重要的核心逻辑全部都是存储过程。 而且就我所知的同行业主流厂商都是在这么做的。具体的好处在做的人都会明白。 所以你不要想当然。 哦，是吗，保险只有核心系统么？我可没说“保险行业全用Java”啊，我是说为什么保险行业为什么不全用存储过程呢？为什么有公司不用存储过程呢？还有你这个主流类比能说明什么问题啊，好比如果是96、97年的时候，你举例说，主流的证券行情客户端软件都跑在DOS上，难道说明DOS比其他操作系统强么？ 那你知道上海证交所实时行情是用什么东西做的么，你用存储过程做做看？我看是你想当然吧。 “具体的好处在做的人都会明白。”，这种空话少说，举出例子来，好处在哪里，比如和C语言比比，好处在哪里？ 建行的证券交易系统就是Java做的核心系统。 几个新起的国外银行在中国的核心系统有不少都是Java的，国内也有用IBM的CICS作交易中间件的，也是java的。 再说了，我没有否定存储过程在特定场景下的作用，你不要以为我是在贬低存储过程，我是在说你不要神化存储过程，一种开发效率低下的、维护成本非常高、业务修改成本极高、难以编写自动回归测试的、没有声明式事务的、没有缓存管理的、没有多线程的、几乎没有什么和其他系统作接口的、大量消耗数据库CPU的、无法轻易扩展的（只能scale up，不能scale out），没有异步消息功能的，没有清晰的内存数据存储模型的，较难复用业务逻辑代码的面向过程数据操纵语言而已。 |
| 返回顶楼 | |
