《存储过程的优缺点个人总结.docx》由会员分享，可在线阅读，更多相关《存储过程的优缺点个人总结.docx（3页珍藏版）》请在三一办公上搜索。
1、存储过程的优缺点个人总结存储过程的优缺点个人总结 公司的系统是自主开发的，历史比较悠久，有不少是传统C/S架构，采用存储过程来处理业务逻辑。 近来做新系统的时候，我采用了三层架构，抛弃存储过程改用ORM。 有同事问及不用存储过程的理由，我想了一下，对存储过程做了如下总结。 本人经验和水平有限，总结有所偏颇，还请大家纠察。 优点 1.在生产环境下，可以通过直接修改存储过程的方式修改业务逻辑，而不用重启服务器。但这一点便利被许多人滥用了。有人直接就在正式服务器上修改存储过程，而没有经过完整的测试，后果非常严重。 2.执行速度快。存储过程经过编译之后会比单独一条一条执行要快。但这个效率真是没太大影响
2、。如果是要做大数据量的导入、同步，我们可以用其它手段。 3.减少网络传输。存储过程直接就在数据库服务器上跑，所有的数据访问都在服务器内部进行，不需要传输数据到其它终端。但我们的应付服务器通常与数据库是在同一内网，大数据的访问的瓶颈会是硬盘的速度，而不是网速。 4.能够解决presentation与数据之间的差异，说得文艺青年点就是解决OO模型与二维数据持久化之间的阻抗。领域模型和数据模型的设计可能不是同一个人，两者的分歧可能会很大这不奇怪，一个是以OO的思想来设计，一个是结构化的数据来设计，大家互不妥协你说为了软件的弹性必须这么设计，他说为了效率必须那样设计，为了抹平鸿沟，就用存储过程来做数据
3、存储的逻辑映射。好吧，台下已经有同学在叨咕ORM了。 5.方便DBA优化。所有的SQL集中在一个地方，DBA会很高兴。这一点算是ORM的软肋。不过按照CQRS框架的思想，查询是用存储过程还是ORM，还真不是问题DBA对数据库的优化，ORM一样会受益。况且放在ORM中还能用二级缓存，有些时候效率还会更高。 缺点 1.SQL本身是一种结构化查询语言，加上了一些控制，但不是OO的，本质上还是过程化的，面对复杂的业务逻辑，过程化的处理会很吃力。这一点算致命伤。 2.不便于调试。基本上没有较好的调试器，很多时候是用print来调试，但用这种方法调试长达数百行的存储过程简直是噩梦。好吧，这一点不算啥，C#
4、/java一样能写出噩梦般的代码。 3.没办法应用缓存。虽然有全局临时表之类的方法可以做缓存，但同样加重了数据库的负担。如果缓存并发严重，经常要加锁，那效率实在堪忧。 4.无法适应数据库的切割。数据库切割之后，存储过程并不清楚数据存储在哪个数据库中。 5.精通SQL的新手越来越少不要笑，这是真的，我面试过N多新人，都不知道如何创建全局临时表、不知道having、不知道聚集索引和非聚集索引，更别提游标和提交叉表查询了。好吧，这个缺点算是凑数用的，作为屌丝程序员，我们的口号是：没有不会的，只有不用的。除了少数有语言洁癖的人，我相信精通SQL只是时间问题。 总结 存储过程最大的优点是部署的方便性可以在生产环境下直接修改虽然滥用的后果很严重。 存储过程最大的缺点是SQL语言本身的局限性我们不应该用存储过程处理复杂的业务逻辑让SQL回归它“结构化查询语言”的功用吧。
