关于存储过程的优缺点

存储过程的使用，好像一直是一个争论。    
  我不倾向于尽可能使用存储过程，是这么认为的：    
  1.   运行速度：   大多数高级的数据库系统都有statement   cache的，所以编译sql的花费没什么影响。但是执行存储过程要比直接执行sql花费更多（检查权限等），所以对于很简单的sql，存储过程没有什么优势。    
  2.   网络负荷：如果在存储过程中没有多次数据交互，那么实际上网络传输量和直接sql是一样的。    
  3.   团队开发：很遗憾，比起成熟的IDE，没有什么很好存储过程的IDE工具来支持，也就是说，这些必须手工完成。    
  4.   安全机制：对于传统的C/S结构，连接数据库的用户可以不同，所以安全机制有用；但是在web的三层架构中，数据库用户不是给用户用的，所以基本上，只有一个用户，拥有所有权限（最多还有一个开发用户）。这个时候，安全机制有点多余。    
  5.   用户满意：实际上这个只是要将访问数据库的接口统一，是用存储过程，还是EJB，没太大关系，也就是说，在三层结构中，单独设计出一个数据访问层，同样能实现这个目标。    
  6.   开发调试：一样由于IDE的问题，存储过程的开发调试要比一般程序困难（老版本DB2还只能用C写存储过程，更是一个灾难）。    
  7.   移植性：算了，这个不用提，反正一般的应用总是绑定某个数据库的，不然就无法靠优化数据库访问来提高性能了。    
  8.   维护性：的确，存储过程有些时候比程序容易维护，这是因为可以实时更新DB端的存储过程，但是在3层结构下，更新server端的数据访问层一样能实现这个目标，可惜现在很多平台不支持实时更新而已。    
   
  从上面可知道，存储过程的使用不能有死规定（全用，或全不用），以前Terminal   -   Server,   Client-DB的方式已经过时了，存储过程很多优势已经不明显。    
  现在，我认为的原则是：所有数据访问在应用层封装为数据访问层，在那里，如果SQL简单的话，直接用SQL；如果SQL复杂，或者数据交互多且中间数据最后不会用到，使用存储过程。其他凭经验吧。