探讨用存储过程的优劣

楼主可以买本Martin Fowler的《企业应用架构模式》仔细阅读一下。
和网友们说的类似，是否使用存储过程，应该依具体情况而定，但这本书讲的更全面和系统。
尤其在项目中，体会更深。
如果继续打算做java或.net开发，这本书必备。另外Martin Fowler其他的书也非常不错。

楼主可以买本Martin Fowler的《企业应用架构模式》仔细阅读一下。
和网友们说的类似，是否使用存储过程，应该依具体情况而定，但这本书讲的更全面和系统。
尤其在项目中，体会更深。
如果继续打算做java或.net开发，这本书必备。另外Martin Fowler其他的书也非常不错。

建议同时看一下<oralce高级编程>这本书，里面对sp讲述得很清楚。

回看楼主：

高并发下，不知道会不会有问题。完成一个业务过程，牵涉到许多表和好几个存储过程，里面有好几处是FOR UPDATE。设计时已经考虑到死锁问题，所以对多张表的更新顺序是保持一致的。但是高并发情况下会不会有性能问题，目前还未测试。如果有谁有经验，还望不吝赐教。

----------------------

这么多不确定能证明存储过程学习成本很低么？

我的理解：
1.对于逻辑密集型的业务系统，比如上面提到的进销存，用存储过程的开发效率至少是用JAVA开发的5倍以上，至于说性能，这个和语言的关系不大，关键在对SQL语句的优化。
2.存储过程学习成本很低，新人培训3天可以直接上手，当然，前提是对业务逻辑比较熟练（话说回来，一个对业务逻辑不熟练的人，什么语言高手都不管用）。
3.一行一行敲代码的程序员们，如果要进步快点，可以多花点时间，换换脑子，多理解理解业务吧，别在这讨论这个语言那个语言的。

sp自然不是万能的，也要分场景使用。
就我个人经验而言，如果一段业务处理放到java代码或者sp里都合适，一般我会优先考虑放到sp。

我维护过所有逻辑放在java代码里的系统，也维护过基本上主要业务处理都放在sp的系统。个人感觉，只要业务熟悉了，并没有太大的差别（只是java代码改动再发布到生产环境比较费时费力）。前提是注释要齐全，代码要规范。

说道需求变动带来的维护工作，我觉得放在sp里面，围绕维护的工作量减少了很多。
就目前进销存的维护而言，客户在各种费用的计算上有很多需求，比如会有很多种计算方式，且要根据系统设置以及客户类型，采用不同的费用计算公式。涉及到各种计算，此时sp的优势就体现出来了。

另，这个项目因为时间非常紧，而人手严重不足，所以我采用的方案，看起来比较极端--涉及到数据库的所有处理，哪怕只是对一张表的CRUD，我全部是用sp的。
这里很多人应该对这样的方案不会赞同。

全部用sp实现，在系统横向扩展上可能会很受限制。但是进销存基本上是企业内部使用的系统，所以并发数并不会非常高，基本上现有架构能支撑住。