一、什么是存储过程
存储过程(Stored Procedure)是在数据库中,一组为了完成特定功能的SQL 语句集,它存储在数据库中,一次编译后永久有效,用户通过指定存储过程的名字并给出参数(可选)来执行
存储过程的优点预编译SQL,提升执行效率
可以隐藏执行逻辑,只暴露名称和参数
相较于程序来说,修改起来更加便捷
存储过程的缺点随着SQL行数的增加,维护复杂度呈线性提升
无法调试,迭代过程中风险较高
二、存储过程的使用思路
提升交付效率
这也是以为存储过程的优点:保存在数据库中,当逻辑需要修改的时候,只需要连接到数据库,修改保存即可,如果逻辑写在程序中,那么就需要编译、打包,部署,尤其是部署的过程会比较麻烦,如果是单台服务器,那么发布的过程中可能会影响用户的使用,如果是多台服务器,那么还需要一台台发布。
对比下来,修改存储过程比修改程序可能要节省30分钟以上的时间
面向数据库开发
关系型数据库中都有完备的用户权限系统,在较为早期ToB的软件系统中,会将有一定商业价值的逻辑以存储过程的方式提供,在软件中只存在存储过程的名称跟参数,软件的开发人员以及甲方的二次开发、对接人员是不接触相关逻辑的,而且这个存储过程还是加密的(SQL Server、Oracle是支持的),程序中只能访问执行存储过程,而且程序中访问数据库的账号,也只有存储过程的执行权限,没有其他权限
这样也可以通过DBA跟Developer的分工,加快开发速度,不过,这已经是过去式了,现在ToB的系统,基本上都已经上云了。
三、到底要不要用存储过程
简单业务系统
如果你开发的是个小系统,没多少业务流程,整体项目只有1个站点或者软件,这个系统的用户量、数据量都很少(例如:个人博客、企业网站、工单系统等),那么把逻辑写在存储过程中,如果碰到问题,可以快速修复,那么在大部分情况下是利大于弊的
复杂业务系统
如果你开发的是有较多业务流程的系统,无论是ToC的电商系统,还是ToB的ERP、CRM、HRM,无论系统承载数据量如何,我都不建议使用存储过程来实现业务逻辑,因为这样的系统业务流程较多,如果将大部分业务逻辑写在存储过程中,随着系统和业务的发展,十几行的存储过程,可能会发展成几十行,几百行甚至上千行,那么为维护,谁头秃~
很简单,存储过程没有现成的调试功能,如果在更新过程中,语法出错,SQL设计器会帮你拦截,但是语法没问题,逻辑出了问题,保存之后,那就会产生一堆脏数据,
就修复数据,就能让人崩溃,更别提造成了业务损失,那可是真金白银就没了
另外,随着系统的发展,如果你是单库单表,随着用户量的增长,单一数据库表无法支撑业务,那么就要做数据库的水平拆分,到时候存储过程全部需要修改测试,就算修改测试通过了,没出问题,那么以后多个库要在同一时间保证存储过程都是一样的逻辑,怎么办?
四、总结
我坚决反对在商业项目中使用存储过程执行业务逻辑
虽然存储过程有诸多优点,在简单业务系统中也可以提高交付效率,但是这在我看来是饮鸩止渴,因为业务和系统总是要发展的,一旦业务和数据量发展到一定程度,贼船难下,为时已晚
如果你真的想在项目中使用存储过程,那就祈祷写存储过程的人都很靠谱,写出来的SQL都很易读,也不会在存储过程中写过于复杂的逻辑,也还好祈祷这个业务/系统不要发展的太好,不然,头发迟早不够用的~
如果是你的个人项目,用不用数据库都无所谓无所谓
永远不要和魔鬼做交易