INSTEAD OF UPDATE触发器仅SQL Server和PostgreSQL真正可用；MySQL完全不支持，Oracle虽语法支持但需视图含ROWID、禁用WITH CHECK OPTION且须手动查主键再更新，落地成本高。
INSTEAD OF UPDATE 触发器只在 SQL Server 和 PostgreSQL 中真正可用
MySQL 完全不支持视图上的 INSTEAD OF 触发器；Oracle 虽然语法上支持，但要求视图必须是行级、不能带 WITH CHECK OPTION，且触发器体中无法直接用 :NEW.column 更新基表——得先查主键再 DML，实际落地成本高。真正能开箱即用、语义清晰的只有 SQL Server 和 PostgreSQL。
SQL Server 中写 INSTEAD OF UPDATE 必须处理 inserted/deleted 表
触发器不会自动知道哪些字段被改了，也不能靠 UPDATE(column) 判断就完事。关键点在于：你得把 inserted 当作新值集合、deleted 当作旧值集合，用 JOIN 或子查询显式关联基表做更新。
-
SET NOCOUNT ON必须加在开头，否则 ORM 或客户端可能因影响行数异常而中断 - 如果视图字段来自多个表（比如
employees.name和departments.loc），触发器里必须分别定位到对应基表，不能混用WHERE条件 - 视图里若含计算列（如
full_name AS first_name + ' ' + last_name），它在inserted表中不可读——别试图取它的值，也别在UPDATE语句里引用它 - 标识列、
timestamp、计算列等不能直接赋值，但可以出现在SET子句中（SQL Server 允许虚值占位），触发器内跳过这些列即可
PostgreSQL 的 INSTEAD OF UPDATE 函数必须返回 trigger 类型并显式处理 NEW/OLD
PostgreSQL 不像 SQL Server 那样提供 inserted/deleted 临时表，而是通过 NEW（新值）和 OLD（旧值）记录变量传入。函数体里不做显式返回，就会报错 trigger function must return trigger。
- 函数返回类型必须是
trigger，结尾必须写RETURN NEW或RETURN OLD（UPDATE 场景通常用RETURN NEW） - 不能假设
NEW字段一定非空——如果视图定义允许某列为 NULL，但基表列是NOT NULL，触发器里就得补默认值或抛出RAISE EXCEPTION - 多行更新？PostgreSQL 的
INSTEAD OF触发器默认是FOR EACH ROW，天然按行处理，不用额外循环，但也要注意事务一致性：比如先更新用户表、再更新订单表，中间失败就得靠整个函数体事务回滚兜底 - 别漏掉
RETURNING子句——如果应用依赖新生成的 ID（比如 ORM 的INSERT ... RETURNING id），触发器里没写，客户端就收不到
Oracle 的 INSTEAD OF UPDATE 触发器最容易因 ROWID 缺失失效
Oracle 要求视图定义里必须显式包含基表的 ROWID 伪列，否则触发器注册成功但根本不会被调用。这不是可选优化项，是硬性前提。
- 建视图时得写类似
SELECT e.rowid AS emp_rowid, d.rowid AS dept_rowid, e.name, d.loc FROM employees e, departments d WHERE ... -
:NEW在触发器里只是只读变量，不能直接用于UPDATE employees SET name = :NEW.name——必须先SELECT id INTO v_id FROM employees WHERE rowid = :NEW.emp_rowid，再用v_id去更新 - 如果视图基于
LEFT JOIN，更新右表字段时要判断:NEW.dept_rowid IS NOT NULL，否则SELECT ... WHERE rowid = NULL会静默失败 - 触发器里不能用自治事务（
PRAGMA AUTONOMOUS_TRANSACTION），否则破坏外层事务原子性——这点常被忽略，导致部分写入成功、部分回滚后数据不一致
复杂视图更新不是“配个触发器就完事”，它把数据库原本拒绝的歧义操作，转化成了你必须亲手写的、带事务边界和错误分支的业务逻辑块。最容易被绕过的点，其实是 NULL 处理、多行兼容性和外键顺序——这三个地方一错，轻则数据丢失，重则约束报错中断整个事务。
