更新计算列应使用触发器还是存储过程？现有触发器写法有何问题

教授的建议本质是从数据库代码的可维护性、可控性角度出发的，核心考量有这几点：

• 触发器是隐式执行的，逻辑对调用方不可见：如果后续维护人员不知道表上绑了这个触发器，排查数据问题时很容易困惑——明明写的更新语句没有修改expiryDate字段，值却自动变化了，在触发器多、业务逻辑复杂的系统里，这类隐式逻辑会大幅提升排障成本。
• 触发器的写法容错率低：SQL Server的触发器是集合级触发而非行级触发，新手很容易写出你当前版本里只处理单行、漏处理批量操作的问题，且触发器运行在原DML语句的事务上下文里，写不好很容易引发长锁、事务回滚异常等问题，故障排查难度比显式调用的存储过程高很多。
• 存储过程的方案不是要求每次手动调用：多数场景下推荐存储过程实现这类逻辑，是要求把表的增改操作统一收口到存储过程，业务侧只允许调用存储过程做数据写入，不允许直接操作表，既可以实现计算逻辑自动执行，又能避免触发器的隐式问题，同时逻辑还能在其他数据订正、批量导入场景复用。

你现在写的触发器确实有几个比较严重的逻辑问题：

• 完全不支持批量操作：SQL Server触发器一次触发会处理所有受影响的行，你用max(orderId)取单条记录的写法，在批量插入/更新多行数据时，只会处理ID最大的那一行，其余记录的expiryDate都不会被计算，必出数据错误。
• 多余的事务控制：触发器本身运行在触发它的外层DML语句的事务中，你手动开启、提交/回滚事务很容易破坏事务原子性，甚至引发事务计数不匹配的报错。
• 触发条件不严谨：你现在只判断inserted表中有没有productionDate非空的行，没有校验productionDate是不是真的从NULL变成了非空，只要productionDate非空，哪怕更新其他不相关的字段也会重复触发计算，做无用功。
• 存在多余的标量子查询：计算日期时反复从inserted表查值，没有利用触发器集合关联的特性，性能差也容易出错。

修正后的触发器代码如下，完全兼容批量操作场景，也符合触发器的编写规范：

create or alter trigger tg_expiry_date
on product
after insert, update
as
begin
    set nocount on; -- 关闭影响行数返回，避免干扰上层应用的逻辑判断

    -- 仅当productionDate字段被修改时才执行后续逻辑
    if update(productionDate)
    begin
        -- 处理更新场景：productionDate从NULL变为非空的记录
        update p
        set p.expiryDate = dateadd(day, 90, i.productionDate)
        from product p
        inner join inserted i 
            on p.orderId = i.orderId
        inner join deleted d 
            on p.orderId = d.orderId
        where 
            i.productionDate is not null 
            and d.productionDate is null;

        -- 处理插入场景：新增时productionDate非空的记录
        update p
        set p.expiryDate = dateadd(day, 90, i.productionDate)
        from product p
        inner join inserted i 
            on p.orderId = i.orderId
        left join deleted d 
            on p.orderId = d.orderId
        where 
            d.orderId is null
            and i.productionDate is not null;
    end
end
go

如果你就是倾向于用触发器实现自动计算，上面的写法完全可以满足需求，比你最初的版本可靠性高很多。实际工程中两种方案没有绝对的对错，只是适用场景不同：存储过程收口的方案更适合团队协作、业务逻辑复杂的系统，触发器更适合小系统、快速实现逻辑的场景。

内容的提问来源于stack exchange，提问作者Héctor Iglesias