别再把业务逻辑塞进数据库了！90%的性能问题都源于这个错误决定
业务逻辑到底该不该写进数据库？这篇文章的作者叫埃瓦尔德·贝内什（Ewald Benes），这位老哥有超过二十年的软件开发经验，他最近写了一篇题为《为什么我把业务逻辑坚决留在数据库之外》的文章，引发了广泛共鸣。
今天我们就来深度拆解一下他的观点，看看这位资深工程师是如何看待“SQL能不能扛起业务大旗”这个问题的。
首先我们得搞清楚什么是“业务逻辑”。简单来说，就是你的App真正要做的事情——比如用户下单后扣库存、发通知、积分加成、优惠券核销；再比如审批流程中根据角色自动流转、风控系统判断是否拦截交易等等。这些都不是简单的增删改查，而是带有规则、条件、状态转换和复杂判断的真实世界行为。
那么问题来了：这些逻辑应该放在哪里执行？是在应用层用Java、Python或者TypeScript来处理，还是通过数据库的存储过程、函数、视图甚至触发器来完成？这其实是一个架构选择，背后牵扯到可维护性、扩展性、团队协作、部署效率等一系列现实问题。
贝内什的观点非常明确：我倾向于把几乎所有代码都放在应用程序里，而把数据库当成一个“ dumb data store ”——也就是一个纯粹的数据存储工具，越傻越好。听起来有点极端是不是？但他说得很有道理。
他认为SQL语言本身就不适合写复杂的业务逻辑。
你想想看，SQL是干什么的？它是为集合操作设计的，擅长的是对成千上万行数据做聚合、连接、筛选。它不是为了处理对象、继承、多态、异常捕获这些面向对象或函数式编程的概念而生的。
举个例子，如果你要在数据库里实现一个订单折扣策略，涉及会员等级、促销活动、地域限制、时间窗口等多个维度，你会发现PL/SQL或者T-SQL写出来就像一坨纠缠不清的面条。变量声明繁琐，控制结构笨重，调试困难，日志几乎没法打。
相比之下，在TypeScript里用几个类+策略模式+依赖注入，三下五除二就搞定了，还能单元测试跑得飞起。
而且还有一个致命问题——部署麻烦。你在应用里改了个bug，CI/CD流水线一键发布，失败了马上回滚。但在数据库里呢？你要申请DBA权限，走审批流程，半夜三更上线，还得担心脚本出错导致锁表、死机、数据损坏。一旦涉及 schema 变更，比如加字段、改类型、重建索引，那更是如履薄冰。很多公司甚至规定数据库变更必须人工审核，不能自动化。这种节奏根本跟不上敏捷开发的步伐。
更别说工具链的问题了！你在IDE里写Java，有自动补全、重构、静态检查、覆盖率分析，整个生态成熟得不得了。可你在Toad或者Navicat里写一段Oracle存储过程？基本上就是裸奔。版本管理靠手动导出.sql文件，调试靠打印日志，出了问题排查起来能让你怀疑人生。团队新人上手成本高，知识难以沉淀，久而久之就成了“只有老张懂”的技术债黑洞。
还有个隐形陷阱叫厂商锁定：你用了PostgreSQL的JSONB高级查询，MySQL不支持；你写了SQL Server的CLR集成函数，迁到Oracle直接报废。一旦业务逻辑深埋在数据库里，换数据库几乎等于重写系统。而应用层代码只要做好抽象，换个ORM适配不同方言，迁移成本低得多。
当然也有人反驳说：“数据库里处理逻辑性能更高啊！”确实，在某些场景下，比如大规模统计报表、实时聚合计算，把运算推到数据旁边能减少网络开销，提升效率。
但这属于特例，不是通则。贝内什提醒我们：不要过早优化。大多数系统的瓶颈不在SQL执行速度，而在架构设计不合理、缓存没用好、N+1查询泛滥。先把逻辑清晰地写在应用层，等真出现性能问题再针对性优化，才是正道。
总结一下，贝内什的核心理念是：让每个组件做它最擅长的事。数据库负责安全、高效、一致地存取数据；应用层负责表达业务意图、组织流程、协调服务。两者各司其职，才能构建出易维护、可扩展、可持续交付的现代系统。
最后他还提到一点很深刻：技术决策不能脱离组织现实。如果你的公司DBA权力极大、运维流程僵化、数据库变更周期长达两周，那你更不应该把关键逻辑塞进数据库。否则每次需求变动都要开会扯皮，开发效率会被拖垮。
所以你看，这不是一场“谁更快”的技术比武，而是一次关于系统长期健康度的战略考量。把业务逻辑留在应用层，不仅是对语言能力的信任，更是对工程实践的尊重。