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