？应用 触发器，函数，存储过程 会 变色

[onhao]

工作中，看到很多文章都是告诫开发者，逻辑控制最好都放到应用层，而且很少看到触发器，函数，存储过程的实际应用，一般都是直接 insert update delete select
这 3 条理由应该都很常见
1.应用了存储过程，函数，等执行效率会下级很多。导致很多人不敢轻易使用上述功能
2.增加开发难度，不但需要维护应用程序代码，还得维护 mysql 的相关代码
3.数据库的计算资源非常宝贵，能在应用层完成 就放在应用层。

然而既然数据库有相关的功能，为什么不利用起来呢？

1.解放双手，少写很多代码。
2.都是代码，理解了代码的功能，一样一样的维护。
3.貌似无法反驳，在极端的情况，少一个资源竞争，多一份稳定。但是应用端的资源也是资源，利用的好应用端资源也给节省了

触发器，函数，存储过程 我们都应用到了
触发器的例子 1： https://wuhao.pw/archives/268/
1.效率。编辑一条数据，这个效率上损失，无伤大雅
2.写好了，几乎不要动了
3.

[wdlth]

现在大都是微服务的设计了，进一步的有 CQRS ，很多数据源是根据领域进行设计的，单个数据库的存储过程难以完成，更别说有分库分表逻辑的大中型系统了。

[onhao]

@adoal #11 有道理文网行业

@cweijan 难读，只要经常接触熟能生巧。写在数据库端，也有他的优势，修改更简洁，部分逻辑直接可修改，可能不需要编译，等步骤。
@supuwoerc 如果在小厂呢？
@aguesuka @jtwor @sujin190 @hand515 确实不好做版本控制，如果一定要做，其实约定好，修改后的相关说明，和普通的代码提交一样。调试的话，可以在备库上进行。

存在既有其存在的意义，工欲善其事,必先利其器。触发器，函数，存储过程 必定也是产品磨刀石，在与怎么用，用得好，恰如其时的用也会事半功倍。

[onhao]

@wdlth 还有很多系统都是中小型的，那么请问中小型系统适用么 ^_^

[hallDrawnel]

无法实现灰度发布之类的吧。我记得存储过程要改就是一把梭改完。如果出问题了回滚也是一把梭回滚（当然数据层面的改动能不能回滚另说）。这样很可怕啊。以及存储过程无法打日志，出问题了只能靠输入输出人脑 debug ？

[2i2Re2PLMaDnghL]

@hallDrawnel 建一张新表叫做 log 把日志打到里面去（

[Fule]

合适的场景用合适的工具，有些场景用存储过程、函数无论是开发难易度、执行效率、部署便利性都是极高的，毕竟数据库就是专业处理集合数据的，对集合数据的处理同等硬件条件下应用层写出花来效率也不会比数据库自己操作高，把数据库擅长的处理放在应用层，更多是牺牲效率换取可伸缩性。要说难以版本管理，确实，不过可以做一些自定义规则和工具缓解。开发不就是一个权衡么，针对特定场景，针对可维护性、执行效率、伸缩性等等一系列因素的侧重点不同，利大于弊就用，弊大于利就不用。触发器的最大的问题在于隐蔽性，属于“偷偷摸摸”就把事儿办了那种，所以这个确实慎用。

[onhao]

@Fule "偷偷摸摸”就把事儿办了那种，哈哈相当形象，贴切。强烈赞同 “合适的场景用合适的工具”

[adoal]

@Fule 还有就是，我听到过一些案例，一开始去关系数据库，后来逐渐在应用层根据业务需求用 Java 代码来实现各种约束和抽象，相当于自己实现了关系数据库的部分功能。那问题来了，我是相信基础设施大厂和知名开源团队里专职做 RDBMS 的研发实力做出的实现呢，还是相信互联网大厂做秒杀出来流到行业信息化里的应用系统架构师们带着一堆北大青鸟、达内的 CRUD boys 在应用层做出的实现呢？

[huiyanpohundh123]

存储过程抽象层级不够，写的代码贼恶心

[adoal]

看下来，对 RDBMS 持反面意见的有三种。

一种是出于架构的角度，尤其是 scalability ，针对互联网大厂的应用场景，高弹性，高并发，数据量巨大，实时一致性要求低，确实知道自己为什么要去 RDBMS 。

一种是出于软工的角度，虽然也可能认同 RDBMS 的高级特性是好东西，但出于版本管理、RDBMS 迁移、CI/CD 的角度，还是选择把数据库当简单的存储表来用，这算是一种 tradeoff ，有舍有得。

还有一种是，没有专职 DBA ，广大“程序员”不懂 RDBMS ，所以把数据库当简单的存储表来用……在这里，程序员三个字可能被简化为这样一种气质（根据我在行业信息化工作中遇到的不少所谓程序员来看），大概自学或者在培训班学习了某门主流编程语言的基本语法，然后就在师傅的带领下进入业务系统的开发，有心于技术的可能会在实践中学习设计模式和软件架构，不是很有心的，可能会去钻研业务场景或者管理知识，慢慢脱离技术岗位。然而即使往高级技术路线走的这些 crud boys 其实技术体系是不扎实也不完整的，他们缺的不只是数据库知识，对操作系统（哪怕不涉及原理和内核，只是生产环境的 Linux 规范化使用和写脚本、业务系统所依赖的基础服务器软件比如 web server 的常用配置）、网络、编程语言（是说编译等，不是指会简单的语法）、信息安全也没有系统化的学习，甚至连培训班这样浮躁的系统化学习都没有。他们认为的开发、编程，在技术层面上就是指会用某种编程语言本身。悲催的是，大多数地方性的、行业性的小信息化公司里这样的程序员还要兼在客户的生产环境上做实施。我遇到过很多这样的乙方程序员甚至技术经理，真的很无奈。

[wdlth]

@onhao 存储过程应该是最常见的，特别是 BI 类的系统，会用存储过程做查询、计算和聚合等。
UDF 函数的也可能使用，不过触发器比较少，性能开销太大了。

[onhao]

触发器是特殊的存储过程，性能开销大，并不妨碍使用他，在低频操作下，用他就很合时宜。甚至高频操作 带来的性能损失只要在一定的可接受范围内都可以用，如果实在有碍于系统运行了，适当的性能调优即可。
@wdlth

[uselessVisitor]

存储过程可读性可太差了，你知道老项目，存储过程里面套了好几个视图，中间表多难看懂吗？
触发器？不懂业务的生产出现问题最多的就是触发器，debug 都不知道数据为啥变了，最后发现是触发器。
函数还行，我们也在用。

[onhao]

@beichenhpy ^_^ 兄台，触发器不是你自己写的吧，上一位兄弟说的非常形象"偷偷摸摸”就把事儿办了那种。你这属于项目交接问题。

[ouyc]

个人看法：并发少的，数据库服务器和应用服务器资源有多余的，写那都可以。并发多的，应用服务器好扩展，数据库怎么扩展？而且本来编程就挺难的，还要整高级 SQL ，还要不要下班了

[onhao]

@ouyc 赞同，合时的运用函数，存储过程，触发器即可，但完全抛弃，避免使用也是个人的自由。权衡利弊，做自己的选择，不听风就是雨即可。