普通视图不能直接UPDATE，因其本质是SELECT查询封装且不对应物理存储；涉及多表JOIN、聚合、DISTINCT或子查询时，数据库无法自动推导修改应影响的基表列。
为什么普通视图不能直接 UPDATE
因为视图本质是 SELECT 查询的封装，不对应物理存储。当视图涉及多表 JOIN、聚合、DISTINCT 或子查询时，数据库无法自动推导出“修改该行应影响哪张基表的哪些列”。INSTEAD OF 触发器就是为这类不可更新视图兜底的机制——它不执行默认行为，而是由你完全接管逻辑。
INSTEAD OF INSERT 必须显式处理每一列映射
触发器不会自动把 INSERT INTO view_name 的值转给基表；你得手动拆解 INSERTED（SQL Server）或 NEW（PostgreSQL）中的字段，并写入对应基表。漏掉一列、类型不匹配、或忽略 NOT NULL 约束，都会导致插入失败。
常见错误现象：The target table 'xxx' of the DML statement cannot have any enabled triggers if the statement contains an OUTPUT clause（SQL Server 下用了 OUTPUT 但触发器未适配）。
实操建议：
- 始终用
SELECT * FROM INSERTED或RAISE NOTICE '%', NEW;（PostgreSQL）先确认实际传入的数据结构 - 对视图中计算列（如
price * qty AS amount）不写入基表，也不在触发器里尝试赋值 - 若基表有自增主键，不要试图向它 INSERT 显式值，除非禁用了 IDENTITY_INSERT
INSTEAD OF UPDATE 要小心处理 WHERE 条件和并发
视图可能由多表 JOIN 构成，UPDATE 语句里的 WHERE 子句只作用于视图逻辑结果，而触发器必须把它“翻译”成对各基表的有效定位条件。比如视图关联 orders 和 customers，UPDATE 的 WHERE order_id = 123 只能用于定位 orders 表，不能直接套在 customers 上。
容易踩的坑：
- 误用
UPDATE customers SET ... FROM INSERTED i JOIN orders o ON i.order_id = o.order_id导致多行更新（当一个客户有多订单时） - 没检查
INSERTED和DELETED中关键字段是否变化，就盲目更新——浪费 I/O，还可能覆盖别人刚改的值 - 没加事务包裹，导致部分基表更新成功、部分失败，视图状态不一致
INSTEAD OF DELETE 需明确级联或限制策略
DELETE 视图某行时，触发器要决定：删基表对应行？置标志位？抛错禁止？这完全取决于业务规则。没有统一答案，但必须显式声明。
例如一个“订单详情视图”含 order_items 和 products，删视图行时：
- 若只删
order_items行，需确保product_id在DELETED中可提取且唯一 - 若想禁止删除已发货订单，就得查
orders.status并RAISERROR或RAISE EXCEPTION - 避免写
DELETE FROM products WHERE product_id IN (SELECT product_id FROM DELETED)—— 这会误删其他订单共用的商品
最易被忽略的一点：触发器里所有 DML 操作都运行在调用语句的同一事务上下文中，但不会自动继承外层的隔离级别或锁提示。如果基表更新涉及高并发写入，得自己加 WITH (UPDLOCK, HOLDLOCK) 或显式 SELECT ... FOR UPDATE，否则可能引发幻读或丢失更新。
