探讨用存储过程的优劣

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

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

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

存储过程的缺点就是对开发人员要求比较高，---你们家就叫菜鸟上？那堪虑啊

MySQL只有InnDB引擎支持事务，同时支持存储过程比较晚，5.0以后才开始支持。在在线事务处理方面积累不如其他数据库。你这个项目其实不太适合用MySQL，用Oracle或者SQLServer会更好。
此外，我对你的优势的说法并不苟同。1说到开发效率，python、Ruby等动态语言进行开发会更快。而且存储过程开发调试局限于数据库本身的数据，自动化单元测试并不方便。2进销存管理系统涉及的数据比较敏感，不建议进行动态更新业务代码。3想使用好SQL并不容易，前端架构简单是用复杂的数据库设计换取的。

其实只要懂sql文，然后再培训一下，基本上菜鸟就能胜任。
首先因为存储过程的写法有规定，sqlexception如何处理，not found如何处理，什么地方写log等等。所以编程人员只需要关注数据从哪儿来，要到哪儿去，期间要更新哪些数据---说白了就是只要懂业务上的事情。
他不需要关注transaction，也不需在java代码里跳转来跳转去，开发工具还能支持单步调试，所以比编程效率更高。

确实，mysql支持存储过程比较晚，这也是我担心的地方。涉及到事务的表，都用InnoDB引擎，其他表都是MyISAM引擎，目前基本没有什么并发，所以这个架构还看不出什么缺陷。

用Oracle也考虑过，毕竟存储过程更强大（例如一个树形结构数据，Oracle处理起来就比MySQL省力不少）。问题是作为一个产品，考虑成本等各种因素还是采用MySQL。Linux/MySQL/Tokyo Cabinet，性能还行。
显然python、Ruby等开发效率更快，奈何没有这个人手啊，完全没时间学习。

忘了说了，我们前端是Flex，所以在传统mvc架构中本应该在java端(controller)的处理逻辑（比如页面跳转等）都交给了前端，所以现在java端的代码非常简单。

我有些收获，请继续发帖。

进销存居然用Flex，这是个什么想法

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



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

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

进销存用flex，是非常合适的。
用户体验远高于html页面，而且客户端编码效率很高。