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

[onhao]

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

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

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

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

[adoal]

因为他们以为他们做的实际并发不超过 10 个的信息系统要面对的应用场景都是阿里爸爸的双 11 秒杀……

[adoal]

以及，他们唯一知道的免费数据库是 MySQL ，这玩意长期以来在数据库高级功能上的实现确实比较烂，靠这些半身不遂的实现还真不如写到应用层。

[MoYi123]

mysql 里各种老版本的问题遗留下来的规矩多的要死.

我在试用期就跑路的一家做电商的公司.
库存总是会产生负数,虽然我也不知道这个东西为什么这么难, 我就建议弄不好就写个存储过程吧, 至少一定不会出问题吧.

得到回应是: 有 bug 事小, 写存储过程坏了规矩事大.

[xgfan]

我来解释下：
1 和 2 是因为大多数开发并不会写，公司也不情愿招一堆 DBA 来写这玩意儿。
3 ，倒不是资源珍贵，而是服务层面的水平扩容和数据库扩容难度不是一个级别的。


简单说，
1 ，公司想省钱，不想买商业软件，也不想额外花钱请 DBA 。
2 ，公司觉得自己以后会很牛逼，不想被绑到某个数据库上。

历史发展的必然。

[hand515]

实际经历过后，我也不推荐用存储过程写业务逻辑
那种痛苦真的是不经历过就体验不到

[thevita]

我觉着可维护性应该不怎么好

[onhao]

@adoal @MoYi123 我觉得很多文章都警告应用这些功能，可能造成一些不好的体验记忆，从而使得一部分人采用跳坑应对。
@xgfan ”水平扩容和数据库扩容难度不是一个级别的。从这个维度来看 确实是
@hand515 @thevita 说说你们的故事，程序都是跟着需求走的，需求变，什么都得变。只要不是太复杂，这些功能函数用对了还是对整个应用系统还是有很积极的作用的。

[zjsxwc]

我只是单纯觉得，如果以后要在存储过程中加业务，比如需要对存储过程业务业务中访问 redis 获取别的数据时，mysql 存储过程里好像很难实现。

[onhao]

@zjsxwc 还是看需求了， 如果需求常常变，只要 mysql 还能胜任，那就无妨。当然像需要 redis 来协作的显然用 存储过程就不适用了。

[wangxin13g]

然后你后期数据要换 pg 换 mariadb 换其他支持 Mysql 协议的数据库,之前的所有用了数据库自带功能的怎么办？

[adoal]

@onhao 因为阿里爸爸之类互联网大厂为社会输送的架构师们薪水高，话语权大，抱团刷价值观，所以在各行各业做传统信息系统的被他们的技术路线绑架了，很少会去考虑这些大厂推崇的技术路线是否适用于自己的场景。

[shuimugan]

用存储过程的话，负载均衡，灰度发布，版本控制，扩容、限流、这些咋搞？
特别是扩展，在 serverless 架构上，你想弹多少个实例都可以，费用也不高，应对高峰期很方便。但是到了数据库升级配置，你可以选一个最高档的看看价格…

[adoal]

建议楼主说说自己工作中所开发出来的系统的实际业务场景，是互联网还是传统信息化。

[cweijan]

存储过程和触发器虽然理论上性能会好点, 但代码相对面向对象语言而言难读, 从而难维护; 现在的系统只希望数据库用于存储数据, 不做应用层的逻辑, 否则相当于需要维护两个应用.

[supuwoerc]

之前 V2 讨论过一次，我看了看，大家一直觉得程序好维护，迭代，排查问题，数据库层面很多开发并不是专门的 DBA ，而很多中小公司是没有专门的 DBA 的，并且貌似还有数据迁移，版本迁移的各种适配问题，数据库版权，服务器扩容成本等等问题，所以开发不愿意用存储过程之类的玩意，后来我问了问在大厂的师兄，他说他工作的两个大厂，6 年时间团队都不让用存储过程。

[aguesuka]

可以实现一个乞丐版的日志, 勉强能在编译前给出编译错误和警告, 虽然没有模块和私有函数不过可以用名称代替, 勉强可以把 create 语句放在 GIT 或 SVN 上, 可以打断点调试, 还能手动执行.

马马虎虎凑合吧, 能有这个想法的人说明没维护过老代码, 体验一下也不失为宝贵经验.

[sujin190]

这和性能不性能的无关吧，和维护及开发效率有关吧

现实来说，太多情况需求三天两头变，很少有按固定产品需求开发测试然后交互就结束的，直接用数据库且不说面对需求频繁改变确实有些吃力，而且吧正因为改变太快太多，所以恰恰需要一个稳定的存储逻辑，业务逻辑做在数据库里你就不怕三天两头改的时候直接把数据库干废了么

再者吧数据库毕竟是查询组织管理数据的，对业务逻辑的表达能力本来也不强，何不把数据和业务流程组织过程放在一起，这样且不说更直观，而且对人员的要求也降低了，毕竟如果后台用 php 的话，招人来做看 php 就行，数据库你会增删改查也就行了，要求可是降低很多的吧

[jtwor]

旧工地就是用存储过程、触发器写业务，代码无法管理控制。存储过程调试依赖工具，生产无日志排除难度高。批量更新触发器就会低效。这还是单表的情况，分表分库运维成本很高。如果换数据库，语法不同又要写一套。还有一个最大的问题，大部分的程序员 sql 水平就删增查改，很多 ORM 用惯了，sql 都不会写的。

[ychost]

一般情况 SQL 都懒得写，ORM 一把梭，只有离线数据分析的时候会用到 SQL ，像阿里的 MaxCompute 都有 Udx 这种插件再 SQL 里面跑 Java Function 也挺舒服的

[hand515]

@jtwor 补充一点，存储过程要做灰度发布、蓝绿发布也很麻烦