在什么情况下用存储过程，以及使用存储过程的优点

比如这1万个请求都是做同一个业务；这个业务需要修改20个表的内容，
那么不用存储过程，就是用一条一条的sql语句实现咯； 就算不直接用sql,也是间接使用吧；
不管你有没有所谓的中间层业务处理服务器，它也要和数据库打交道吧；

试想一下，提交20条sql，那么就是和数据库服务器通讯20次；而存储过程只需要一次通讯，避免了很多无谓的中间信息反馈；

也就是说同时1万个并发，如果是存储过程实现，数据库服务器需要做1万次通讯；
如果是通过中间服务器，一条条通过sql通讯，那么修改20个表，至少20条sql，所以通讯20万次；
我不明白高并发和存储过程有何关系？ 这两个本来就不属于矛盾体；

因为数据的更新，是数据库服务器必须要做的，中间业务层服务器是帮不上忙的；
就像皇帝生病了，只能自己受苦；那么多亿万子民谁也不能分担；
所以，我很难理解：如果用了存储过程，服务器承受不了；那么不用存储过程，服务器怎么就能承受的了了？
用不用存储过程，跟服务器是不是负担变大了，没有本质联系；该做的是一个都不能少,用存储过程的好处，是减少了大量不必要的中间数据传递，从这个角度来说，用了存储过程，特别对复杂的业务来说，确实大大的降低了压力；

当然，如果有些复杂的算法，确实可以通过把数据先取到中间层业务服务器上，通过c#，java之类的程序来运算；避免了这些算法直接在数据库端运算；不过，我感觉大部分系统，很少用到什么复杂的算法，绝大多数都是简单的排序，分组，几个表之间的互相insert，update之类；这些本来就基本在数据库服务器上实现的；
   我个人感觉存储过程的好处是：
      1.事务好控制，因为存储过程本身就是一个事务的整体；当如果写在java,c#这样的程序里，通过直接或间接的sql和数据库大交道，一个个大大小小的函数互相嵌套，搞不好，事务控制不好，那就出了大问题；
      2.数据库的优化好处理，如果发现速度慢了，可以很容易在数据库层面找到究竟是那个存储过程的第几行的那个sql写的不够好，我们可以对其优化，提高效率；但是把这个sql直接或间接的写在中间层服务程序的java或C#里，不是那么方面找出来，就算找出来，修改麻烦，而且修改好了，要重现编译class或dll，再重新发布；
      3.轻量级的修改成本，如果业务做些微调，简单的修改下对应的存储过程，编译一下，实时使用，对用户来说，根本感觉不到你的修改；现在流行动态语言大行其道，也是其修改的便利性；而用那么多框架写成的中间层修改就麻烦些了；最起码的要有环境吧，搞java的，必须要有jdk，还要有ssh框架之类;搞net的，要安装了几个G的vs2008之类； 我们距一个场景： 如果仅仅是修改某条sql的一个简单的where条件；作者可以不必自己修改，他可以转告其他人，告诉修改那里，那么那个人基本不要什么环境，有个sqlplus，或者一些第三方工具toad,plsql dev 之类即可；甚至直接在web上调出数据库过程，进行修改；而如果要修改C#之类就麻烦了，就算知道在那里修改，至少要有环境吧，那行，至少所有人都装几个G的vs2008,而且必须很严格的所有人代码同步；当然患有可能一大堆得第三方控件也要装吧；
    4.学习成本，存储过程掌握起来，简单容易单一；但是如果通过各种前台语言就麻烦了，有的项目用java,c#,有的项目用python，有的用perl，有用php...;而且还有那么多框架；项目实施到一半，经常换人；以后维护，也换人；存储过程人人都会；复杂的逻辑在存储过程里实现维护成本低；
    5.很多人写的SQL都是硬编码，虽然尽量使用带变量绑定的SQL是常识问题，但是还是有很多人犯这个低级错误；用存储过程，通过监控共享区的sql,发现存储过程里会自动变成绑定变量的SQL；