ORA-01779错误源于Oracle要求被更新列必须来自“键保留表”，即连接结果中每行须唯一映射回原表一行；若右表无主键/唯一约束、存在多对一匹配或视图未暴露唯一键，Oracle无法保证更新确定性，故报错拒绝执行。
因为数据库无法把 UPDATE 语句唯一映射到右表的某一行——它根本不知道你改的是哪个 orders.id，尤其当右表字段为 NULL 或视图没暴露主键时，报错是必然结果，不是配置或权限问题。
ORA-01779 / “not key-preserved” 错误从哪来
这类错误本质是数据库在执行 UPDATE v SET status = 'shipped' 前，试图反向定位「该更新基表 orders 的哪一行」。LEFT JOIN 视图中，orders.status 可能来自多行、单行，甚至全为 NULL；如果视图定义里没包含 orders.id（或右表其他唯一非空列），数据库就彻底失去锚点。
- Oracle 报
ORA-01779：右表未“key-preserved”，即连接后每行不能保证对应唯一基表行 - SQL Server 报
Msg 4405：“affects multiple base tables”，因视图含 JOIN，DML 语义不明确 - PostgreSQL 报
ERROR: cannot update a join view或column reference is ambiguous，连列归属都分不清
为什么加 WHERE 条件也不管用
常见误区是以为写 WHERE user_id = 123 就能锁定右表行——但这个条件只作用于视图结果集，不是基表。如果右表有多个 order 关联同一 user_id，触发器内不做显式去重，就会批量更新所有匹配订单。
-
SELECT * FROM inserted返回的是整批变更行，不是单行变量；用SELECT TOP 1 @id = id FROM inserted只处理第一行，其余静默丢弃 - 若视图里
orders.status允许为NULL，而基表status是NOT NULL，触发器没提供默认值就会直接报错 - 忽略事务边界：没加
BEGIN TRY ... COMMIT，部分更新失败后状态不一致
LEFT JOIN 视图里 NULL 值怎么安全参与更新
右表字段为 NULL 不代表“不该更新”，而是意味着当前没有对应记录——你需要决定是插入新行、跳过、还是设默认值。这无法由数据库自动推断，必须在触发器里显式分支。
- 用
EXISTS (SELECT 1 FROM orders WHERE id = i.order_id)判断是否已存在，再决定UPDATE还是INSERT - 对可能为
NULL的输入字段，用ISNULL(i.status, 'pending')或COALESCE(i.status, 'pending')提供兜底 - 避免在
WHERE子句中写orders.status IS NOT NULL——这会把左表无匹配的行全过滤掉，违背 LEFT JOIN 本意；应把过滤逻辑移到ON或触发器内部
真正难的不是写触发器语法，而是厘清业务语义：这一行更新，到底想改变哪张表、哪一行、在什么前提下生效。漏掉任意一个判断分支，数据就可能错位或静默丢失。
