SQL更新逻辑：单独写SQL、整体更新还是动态SQL？-优快云博客

本文链接：https://blog.youkuaiyun.com/qiuriyuchen/article/details/132972942

讨论在SQL中处理逻辑的方式，包括为每个业务单独编写SQL，整体更新所有字段，还是根据传入对象动态构建SQL。分析了三种方案的优缺点，建议根据业务需求和DDD原则选择合适的方法。单独写SQL便于限制数据修改，更符合DDD的Repository模式是业务最灵活但映射问题较复杂，动态SQL不被推荐，因为它在业务体验和设计原则间摇摆不定。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

SQL中是否应该写逻辑

问题

如果我们有不同业务需要更新表的不同字段，我们是应该为每个业务单独写SQL，还是写个更新全部字段的SQL，还是写个动态SQL根据传入的对象非空拼接？

问题举例-用户信息更改

用户信息

我们需要实现三个用例：

方案一：单独写Sql

如果不使用DDD，对业务还是很友好的，DAO层保证了不可以随便修改数据；很多人认为这种写法让DAO介入了业务，可以用依赖倒置来解释，DAO的实现类知识实现了业务层定义的三个接口方法，DAO并不知道真实的业务。

方案二：整体更新

更新传入的对象的所有字段，符合DDD的Repository的做法，完全依赖业务逻辑控制。

方案三：动态Sql

根据传入的值非空来判断执行的sql,个人非常不推荐这种写法，对业务体验很差。两头都不靠，不是DDD，也不是业务的SQL。

update User set
<isNotEmpty property="email">
  email=#email#
</isNotEmpty>
<isNotEmpty property="pwd">
  pwd=#pwd#
</isNotEmpty>
<isNotEmpty property="pin">
  pin=#pin#
</isNotEmpty>
此处省略其他字段，这种写法为了共用这个Sql，一般会写上User的所有字段
where id=#id#

最后给个整体对比图，可以思考写不同的优缺点，第一种我认为是很多企业在用的，没有太大问题；第二种是DDD的，对业务支撑最灵活，但目前数据库和DDD对象(聚合根)不太匹配，不太好映射，使用较少(我在一些项目上，直接使用聚合根Json化存储，不存在映射问题，业务可以使用DDD建模，实际证明对业务的支撑非常好)；第三种不推荐。