oracle复杂视图默认不可更新，唯一解法是定义instead of触发器；它完全替代dml操作，必须带for each row，禁止递归调用视图，主从表操作须严格顺序，权限需直接授予且调试需实测捕获异常。
Oracle 中的复杂视图（如多表连接、含聚合、DISTINCT、UNION 等）默认不支持 INSERT/UPDATE/DELETE，直接操作会报 ORA-01779 或 ORA-01732。唯一可靠解法是定义 INSTEAD OF 触发器 —— 它不是“辅助执行”，而是完全替代原 DML 操作，由你手写逻辑把视图操作映射到基表。
为什么必须用 INSTEAD OF 触发器而不是 BEFORE/AFTER？
INSTEAD OF 是唯一允许作用于视图的触发器类型；BEFORE 和 AFTER 只能用于表。Oracle 在遇到对不可更新视图的 DML 时，根本不会尝试修改基表，而是直接拒绝 —— 所以没有“先执行再触发”的机会。只有 INSTEAD OF 能拦截这个动作，接管全部逻辑。
- 触发器必须带
FOR EACH ROW，否则无法访问:new和:old - 不能加
WITH CHECK OPTION，否则视图定义和触发器行为可能冲突 - 触发器体里不能调用
INSERT INTO 视图，会递归死循环
INSERT 场景下如何拆分数据并保证主从一致性？
典型场景：视图背后是一对多关系（如 V_MAIN_DETAIL 展示主表 + 多个从表记录），用户插入一条带逗号分隔字符串的行（如 GRANTEES = 'u1,u2,u3'）。触发器需手动解析、生成主键、分别写入主表和从表。
- 主表插入必须在从表前完成，否则从表外键或关联字段无值可填
- 推荐用
sys_guid()或序列生成主键，避免并发冲突 - 字符串解析建议用
CONNECT BY游标（如知识库中cur_GRANTEE），不用正则（Oracle 10g/11g 正则性能差且易出错） - 务必检查
:new字段是否为空，例如if :new.GRANTEES is null then raise_application_error(-20000, '...');
UPDATE 和 DELETE 的关键约束与常见坑
对复杂视图做 UPDATE 或 DELETE 时，Oracle 不知道该改哪张基表的哪一行 —— 所以触发器必须自己判断依据，并显式写出所有 WHERE 条件。
-
UPDATE中，:old提供原始值（如主表GUID），:new提供目标值；但多表场景下，通常只能更新主表字段，从表需按业务逻辑决定是否同步更新 -
DELETE必须先删从表，再删主表，顺序反了会违反外键约束 - 如果视图字段来自多个表的同名列（如两个表都有
ID），:new.ID实际指向的是视图 SELECT 列别名，不是某张表的物理列 —— 写 SQL 时必须明确指定基表字段 - 不要依赖
ROWID，视图无真实ROWID，用主键或唯一组合字段定位
权限与调试中最容易被忽略的点
即使触发器语法全对，也可能因权限或视图结构失败 —— 这些问题往往不报语法错误，而是静默失败或抛出模糊异常（如 ORA-01031: insufficient privileges）。
- 触发器所有者必须对涉及的所有基表有
INSERT/UPDATE/DELETE权限，且是直接授权，不能通过角色继承 - 如果视图定义里引用了
DUAL或其他只读对象，哪怕没用到那部分字段，整个视图仍被 Oracle 判定为不可更新，INSTEAD OF也救不了 - 调试时别只查触发器编译状态（
SELECT status FROM user_objects WHERE object_name = 'TRI_V_MAIN_DETAIL'），要实际执行 DML 并捕获SQLERRM，或在触发器里加DBMS_OUTPUT.PUT_LINE（需提前SET SERVEROUTPUT ON）
