探讨用存储过程的优劣

其实存储过程的开发效率和可维护性都低于java,ruby等高级语言，使用存储过程最大的好处是性能。所以不建议在对性能要求不高的地方大规模使用存储过程。



不是很了解mysql的存储过程，但你上面说的对oracle的存储过程绝对不成立。写stored procedure比写java要理解更多非业务的技术细节。存储过程的高性能取决于程序员对数据库底层实现方式的了解。菜鸟可以写，但写出来的质量的确堪忧。

只是你们业务逻辑简单。且在开发阶段。才有这种幻觉。
要是你们业务逻辑复杂。而且你正好在维护阶段。你会有骂娘的冲动的。
PS.过马路的时候多扶扶老奶奶，积攒点RP。你做了孽。让维护人员来受，这个孽，是大大滴。当然，如果你们自己维护，祝君好运。能否把这个项目的维护公司介绍一下。以后打死我也不投了。

有一个进销存项目，时间比较赶所以架构设计的时候将服务器端的业务实现，全部归到了存储过程。目前项目主体已经结束，想探讨一下此设计的优劣。
优势：
1、开发效率高。java端代码量很少，基本上是将客户端的数据，原原本本传入到mysql的存储过程。所有的计算都在存储过程里完成，开发调试方便。
2、维护方便。一般后台有什么错误，都在存储过程里，修改完了不需要重启服务，基本不会干扰客户运营。
3、架构简单。即便是新手，只要懂sql语法，再培训一下存储过程知识，完全能胜任后台维护。

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

暂时想到这么些，如果谁对mysql的存储过程机制比较熟悉，此种机制若有问题，还希望多多指教啊。

其实存储过程的开发效率和可维护性都低于java,ruby等高级语言，使用存储过程最大的好处是性能。所以不建议在对性能要求不高的地方大规模使用存储过程。



不是很了解mysql的存储过程，但你上面说的对oracle的存储过程绝对不成立。写stored procedure比写java要理解更多非业务的技术细节。存储过程的高性能取决于程序员对数据库底层实现方式的了解。菜鸟可以写，但写出来的质量的确堪忧。

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

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