|
锁定老帖子 主题：探讨用存储过程的优劣
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-15
最后修改：2011-01-15
sp自然不是万能的，也要分场景使用。
就我个人经验而言，如果一段业务处理放到java代码或者sp里都合适，一般我会优先考虑放到sp。 我维护过所有逻辑放在java代码里的系统，也维护过基本上主要业务处理都放在sp的系统。个人感觉，只要业务熟悉了，并没有太大的差别（只是java代码改动再发布到生产环境比较费时费力）。前提是注释要齐全，代码要规范。 说道需求变动带来的维护工作，我觉得放在sp里面，围绕维护的工作量减少了很多。 就目前进销存的维护而言，客户在各种费用的计算上有很多需求，比如会有很多种计算方式，且要根据系统设置以及客户类型，采用不同的费用计算公式。涉及到各种计算，此时sp的优势就体现出来了。 另，这个项目因为时间非常紧，而人手严重不足，所以我采用的方案，看起来比较极端--涉及到数据库的所有处理，哪怕只是对一张表的CRUD，我全部是用sp的。 这里很多人应该对这样的方案不会赞同。 全部用sp实现，在系统横向扩展上可能会很受限制。但是进销存基本上是企业内部使用的系统，所以并发数并不会非常高，基本上现有架构能支撑住。 |
| 返回顶楼 | |
|
发表时间：2011-01-15
最后修改：2011-01-15
archerfrank 写道 glovebx 写道 有一个进销存项目，时间比较赶所以架构设计的时候将服务器端的业务实现，全部归到了存储过程。目前项目主体已经结束，想探讨一下此设计的优劣。
优势： 1、开发效率高。java端代码量很少，基本上是将客户端的数据，原原本本传入到mysql的存储过程。所有的计算都在存储过程里完成，开发调试方便。 2、维护方便。一般后台有什么错误，都在存储过程里，修改完了不需要重启服务，基本不会干扰客户运营。 3、架构简单。即便是新手，只要懂sql语法，再培训一下存储过程知识，完全能胜任后台维护。 劣势： 1、无法跨数据库。目前架构只能支持mysql 2、高并发下，不知道会不会有问题。完成一个业务过程，牵涉到许多表和好几个存储过程，里面有好几处是FOR UPDATE。设计时已经考虑到死锁问题，所以对多张表的更新顺序是保持一致的。但是高并发情况下会不会有性能问题，目前还未测试。如果有谁有经验，还望不吝赐教。 暂时想到这么些，如果谁对mysql的存储过程机制比较熟悉，此种机制若有问题，还希望多多指教啊。 你们的系统有多少存储过程?会不会有大量的复制粘贴代码?日后维护时修改了东西，如何回归测试? 目前有近300个存储过程，基本上所有的存储过程头尾的写法是一致的，头部就是变量定义和sqlexception以及not found的处理，还有out参数的初始化处理。尾部可能会有写日志处理，如果是嵌套在transaction里的话此sp就不写日志。 另外，并没有复制粘帖的代码，sp经过规划，一些通用的sp都抽出来了。 维护阶段有修改，先会在跟生产环境一致的测试环境中修改测试，基本上就是拿生产环境的数据黑盒过所有的条件分支，OK就发布。 |
| 返回顶楼 | |
|
发表时间：2011-01-16
SQL/SP很容易写， 而且很容易写得很烂
|
| 返回顶楼 | |
|
发表时间：2011-01-16
icefishc 写道 SQL/SP很容易写， 而且很容易写得很烂
让你说中了，我就写的很烂。 |
| 返回顶楼 | |
|
发表时间：2011-01-16
国内某家公司就用存储过程给银行做核心系统，可能起来比较头疼。
|
| 返回顶楼 | |
|
发表时间：2011-01-16
LZ是不是在炫耀他自己写了300个存储过程呢...
MYSQL的DBA比ORACLE的DBA要贵很多，你就知道用MYSQL写存储过程是多么昂贵的一件事情... |
| 返回顶楼 | |
|
发表时间：2011-01-16
wavelet 写道 LZ是不是在炫耀他自己写了300个存储过程呢...
MYSQL的DBA比ORACLE的DBA要贵很多，你就知道用MYSQL写存储过程是多么昂贵的一件事情... 千万别这么说，本人无意炫耀什么东西。 纯技术讨论贴，拜托请别歪了楼。 |
| 返回顶楼 | |
|
发表时间：2011-01-17
最后修改：2011-01-17
govista 写道 我的理解：
1.对于逻辑密集型的业务系统，比如上面提到的进销存，用存储过程的开发效率至少是用JAVA开发的5倍以上，至于说性能，这个和语言的关系不大，关键在对SQL语句的优化。 2.存储过程学习成本很低，新人培训3天可以直接上手，当然，前提是对业务逻辑比较熟练（话说回来，一个对业务逻辑不熟练的人，什么语言高手都不管用）。 3.一行一行敲代码的程序员们，如果要进步快点，可以多花点时间，换换脑子，多理解理解业务吧，别在这讨论这个语言那个语言的。 回看楼主： 高并发下，不知道会不会有问题。完成一个业务过程，牵涉到许多表和好几个存储过程，里面有好几处是FOR UPDATE。设计时已经考虑到死锁问题，所以对多张表的更新顺序是保持一致的。但是高并发情况下会不会有性能问题，目前还未测试。如果有谁有经验，还望不吝赐教。 ---------------------- 这么多不确定能证明存储过程学习成本很低么？ |
| 返回顶楼 | |
|
发表时间：2011-01-17
ray_linn 写道 govista 写道 我的理解：
1.对于逻辑密集型的业务系统，比如上面提到的进销存，用存储过程的开发效率至少是用JAVA开发的5倍以上，至于说性能，这个和语言的关系不大，关键在对SQL语句的优化。 2.存储过程学习成本很低，新人培训3天可以直接上手，当然，前提是对业务逻辑比较熟练（话说回来，一个对业务逻辑不熟练的人，什么语言高手都不管用）。 3.一行一行敲代码的程序员们，如果要进步快点，可以多花点时间，换换脑子，多理解理解业务吧，别在这讨论这个语言那个语言的。 你那么坚持自己的想法，还讨论个鬼？我投个隐藏 不是同一个人啊，LZ杯具 |
| 返回顶楼 | |
|
发表时间：2011-01-17
xieye 写道 ray_linn 写道 govista 写道 我的理解：
1.对于逻辑密集型的业务系统，比如上面提到的进销存，用存储过程的开发效率至少是用JAVA开发的5倍以上，至于说性能，这个和语言的关系不大，关键在对SQL语句的优化。 2.存储过程学习成本很低，新人培训3天可以直接上手，当然，前提是对业务逻辑比较熟练（话说回来，一个对业务逻辑不熟练的人，什么语言高手都不管用）。 3.一行一行敲代码的程序员们，如果要进步快点，可以多花点时间，换换脑子，多理解理解业务吧，别在这讨论这个语言那个语言的。 你那么坚持自己的想法，还讨论个鬼？我投个隐藏 不是同一个人啊，LZ杯具 哈哈，看错了，给lz说sorry了 |
| 返回顶楼 | |
