|
锁定老帖子 主题：探讨用存储过程的优劣
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-21
以前没想过这种方法，让我对存储过程有了新的认识。
|
| 返回顶楼 | |
|
发表时间：2011-01-21
处理一大堆数据，最后得到几条返回结果
这种情况比较适合存储过程 |
| 返回顶楼 | |
|
发表时间：2011-01-21
lobbychmd 写道 ironsabre 写道 lobbychmd 写道 存储过程只不过是预编译而已，能快到哪去啊？
效率多取决于代码的质量，对关系数据库的理解，不管用 sp 还是 orm 都是一样的。 说白了存储过程就是把标准 sql 这样一种经典的DSL，扩展为功能简单平淡无奇的解释运行的脚本语言， 表现能力有限，要复用和理解都不是那么容易。跟UI 的结合更没有一般的编程开发语言方便了。 sp快最主要的原因是：省掉了app server和db server之间的通信成本。 比如一个复杂的逻辑可能需要跟db交互100次，而如果在sp里，这里的100次通信成本就没了。 如果sp 可以实现那说明 这100 次交互是没那么必要的。 或者从另外的角度说 db server 承担了这些交互的一个变形，加重负担了 你明白我的意思吗？我说的是通信成本。而不是sql本身执行的成本。 这样可以帮助你理解，你现在假设app server和db server是通过56k的网速来连接的。 （这当然不是现实的，但这种把网速的慢放大可以帮助你理解通信成本。） 设每次app->db需要1秒通信时间，而db执行本身只需要0.01秒。 那么你需要花掉(1+0.01) * 100 = 101秒。 而使用pl/sql只需要1 + 0.01 * 100 = 2秒。 另外：db比有些人想像中的要强大很多。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
ironsabre 写道 lobbychmd 写道 ironsabre 写道 lobbychmd 写道 存储过程只不过是预编译而已，能快到哪去啊？
效率多取决于代码的质量，对关系数据库的理解，不管用 sp 还是 orm 都是一样的。 说白了存储过程就是把标准 sql 这样一种经典的DSL，扩展为功能简单平淡无奇的解释运行的脚本语言， 表现能力有限，要复用和理解都不是那么容易。跟UI 的结合更没有一般的编程开发语言方便了。 sp快最主要的原因是：省掉了app server和db server之间的通信成本。 比如一个复杂的逻辑可能需要跟db交互100次，而如果在sp里，这里的100次通信成本就没了。 如果sp 可以实现那说明 这100 次交互是没那么必要的。 或者从另外的角度说 db server 承担了这些交互的一个变形，加重负担了 你明白我的意思吗？我说的是通信成本。而不是sql本身执行的成本。 这样可以帮助你理解，你现在假设app server和db server是通过56k的网速来连接的。 （这当然不是现实的，但这种把网速的慢放大可以帮助你理解通信成本。） 设每次app->db需要1秒通信时间，而db执行本身只需要0.01秒。 那么你需要花掉(1+0.01) * 100 = 101秒。 而使用pl/sql只需要1 + 0.01 * 100 = 2秒。 另外：db比有些人想像中的要强大很多。 顶最后一句话，事实上很多人都把db仅仅当作是一个存放数据的地方。而由于对存储过程的不熟悉，一谈起存储过程就只想到编码麻烦、调试麻烦。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
lobbychmd 写道 存储过程只不过是预编译而已，能快到哪去啊？
效率多取决于代码的质量，对关系数据库的理解，不管用 sp 还是 orm 都是一样的。 说白了存储过程就是把标准 sql 这样一种经典的DSL，扩展为功能简单平淡无奇的解释运行的脚本语言， 表现能力有限，要复用和理解都不是那么容易。跟UI 的结合更没有一般的编程开发语言方便了。 看场景，有些场景下，用存储过程会快很多。比如数据汇总计算等。 存储过程不会直接跟UI结合，他只是返回UI需要的数据，所以不存在跟UI结合方便与否之说。 另，现在有种方案，是客户端页面通过代码访问存储过程，获取json格式的数据，直接表现。 省略了中间架构，听上去是不是很极端？根据场景，也许不失为一种解决方案。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
ironsabre 写道 seya 写道 把业务逻辑写到存储过程，是种很不好的实现方式。因为一般随着业务的增大，逻辑的复杂，性能会逐渐下降，后面你会发现MySQL已经无法满足你的需求，得换Oracle或者SQLServer， 或者做一些迁移，集群之类的，一般需要改变的都是数据库，而不是前端或者服务器Java代码，这样你那些写在数据库里面的东西都得改，数据库写的越多，工作量越大。
我见过的逻辑复杂的超大业务系统都喜欢用存储过程。 有时候也不一定是喜欢，而是你只能那么做。复杂逻辑如果堆积到代码里，那修改维护甚至扩展会成为噩梦的。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
ironsabre 写道 liangguanhui 写道 ray_linn 写道 govista 写道 我的理解：
1.对于逻辑密集型的业务系统，比如上面提到的进销存，用存储过程的开发效率至少是用JAVA开发的5倍以上，至于说性能，这个和语言的关系不大，关键在对SQL语句的优化。 2.存储过程学习成本很低，新人培训3天可以直接上手，当然，前提是对业务逻辑比较熟练（话说回来，一个对业务逻辑不熟练的人，什么语言高手都不管用）。 3.一行一行敲代码的程序员们，如果要进步快点，可以多花点时间，换换脑子，多理解理解业务吧，别在这讨论这个语言那个语言的。 回看楼主： 高并发下，不知道会不会有问题。完成一个业务过程，牵涉到许多表和好几个存储过程，里面有好几处是FOR UPDATE。设计时已经考虑到死锁问题，所以对多张表的更新顺序是保持一致的。但是高并发情况下会不会有性能问题，目前还未测试。如果有谁有经验，还望不吝赐教。 ---------------------- 这么多不确定能证明存储过程学习成本很低么？ 难道你这些FOR UPDATE，你换成Java就不再需要了吗？要锁的表，用哪种方法还是要锁的…… 这句话对头，这跟用什么语言没有任何关系。 我见过有人做企业开发很多年了，连select for update是干什么的都不知道。 如果更新逻辑放在代码里，一般我会倾向用乐观锁来处理，每次更新的时候判断revision是否一致，不一致则报错。 放入sp之后，乐观锁报错造成的交互比较难于控制，所以用了悲观锁，直接锁定，省事。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
sunshunbo 写道 以前没想过这种方法，让我对存储过程有了新的认识。
很高兴能给他人一点点启发。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
ironsabre 写道 lobbychmd 写道 ironsabre 写道 lobbychmd 写道 存储过程只不过是预编译而已，能快到哪去啊？
效率多取决于代码的质量，对关系数据库的理解，不管用 sp 还是 orm 都是一样的。 说白了存储过程就是把标准 sql 这样一种经典的DSL，扩展为功能简单平淡无奇的解释运行的脚本语言， 表现能力有限，要复用和理解都不是那么容易。跟UI 的结合更没有一般的编程开发语言方便了。 sp快最主要的原因是：省掉了app server和db server之间的通信成本。 比如一个复杂的逻辑可能需要跟db交互100次，而如果在sp里，这里的100次通信成本就没了。 如果sp 可以实现那说明 这100 次交互是没那么必要的。 或者从另外的角度说 db server 承担了这些交互的一个变形，加重负担了 你明白我的意思吗？我说的是通信成本。而不是sql本身执行的成本。 这样可以帮助你理解，你现在假设app server和db server是通过56k的网速来连接的。 （这当然不是现实的，但这种把网速的慢放大可以帮助你理解通信成本。） 设每次app->db需要1秒通信时间，而db执行本身只需要0.01秒。 那么你需要花掉(1+0.01) * 100 = 101秒。 而使用pl/sql只需要1 + 0.01 * 100 = 2秒。 另外：db比有些人想像中的要强大很多。 主要是 db server 是不能 scale out 的，你如果找一个这么慢的网络来举例的话，囧，那我只能说还是看具体应用吧。 db server 做的事情单纯一些有利于系统的可伸缩性。 |
| 返回顶楼 | |
|
发表时间：2011-01-21
glovebx 写道 lobbychmd 写道 存储过程只不过是预编译而已，能快到哪去啊？
效率多取决于代码的质量，对关系数据库的理解，不管用 sp 还是 orm 都是一样的。 说白了存储过程就是把标准 sql 这样一种经典的DSL，扩展为功能简单平淡无奇的解释运行的脚本语言， 表现能力有限，要复用和理解都不是那么容易。跟UI 的结合更没有一般的编程开发语言方便了。 看场景，有些场景下，用存储过程会快很多。比如数据汇总计算等。 存储过程不会直接跟UI结合，他只是返回UI需要的数据，所以不存在跟UI结合方便与否之说。 另，现在有种方案，是客户端页面通过代码访问存储过程，获取json格式的数据，直接表现。 省略了中间架构，听上去是不是很极端？根据场景，也许不失为一种解决方案。 例如你不能在执行了一半的时候弹出一个确认的选择对话框 |
| 返回顶楼 | |
