业务逻辑写在存储过程还是后台代码？

业务逻辑写在存储过程还是后台代码？

就这个问题，要看所属的行业和所做的业务，需要区别对待。

因为业务要求不一样，传统软件开发（如电信、银行、金融行业）和互联网Web开发的思维方式不一样。

传统的软开行业考虑业务的稳定性、安全性、系统性能；后者主要考虑扩展性、快速迭代、高并发、低成本。

下面说说两者的优势：

1 存储过程优势

• 性能效率高

  因为存储过程已经预先编译，不需要经过数据库服务器解析，执行速度更快

• 安全性好、稳定性高

  调用存储过程只需要参数输入，防止SQL注入，屏蔽了数据库的表结构，隐藏核心业务逻辑。适合银行、国企的诉求。

• 大批量数据处理能力强

  存储过程中的脚本经过高度优化，提高大量数据处理时系统的性能。

2 后台代码优势

• 扩展性、维护性好

  业务逻辑写到存储过程中不利于系统分层设计和维护，移植性差，更不利于数据库的迁移。但在后台代码中，可以方便业务拆分扩张。

• 可读性好，业务逻辑更改容易

  互联网行业的业务需求迭代较快，若写在存储过程中，后来的开发人员更改难度较大，不易于快速迭代。

• 业务扩展的成本低

  目前服务器等硬件设备成本低，数据库的性能问题可以从硬件设施上得到解决（如弄个mysql主从架构其实就把负载问题给解决了）。如google、阿里巴巴其实会通过很多mysql集群来提高性能。

• 工作量相对存储过程较小

  开发存储过程涉及开发人员的工作量较大（考虑到设计与优化），成本高。

在互联网高并发，大流量的情况下，成熟的做法都是，把业务逻辑要交给应用程序处理，数据库做擅长的事情（只是存储数据），减少数据库资源消耗。尽量少让数据库去做运算(也就是ifelse之类的逻辑判断)。数据库的性能瓶颈用缓存来解决，在缓存中运算。

电信，金融这些企业占据了很大的资源优势，把安全和稳定放在第一位，可以提供好的机房(带宽和网络稳定优势)。oracle数据库上千万的费用都能承受。同时业务变化小，不用频繁更改存储过程逻辑。

总结，根据需求和成本选择实现方式。

参考: https://blog.csdn.net/weixin_34115824/article/details/85597345?spm=1001.2101.3001.6650.4&utm_medium=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~default-4.pc_relevant_paycolumn_v2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~default-4.pc_relevant_paycolumn_v2&utm_relevant_index=6