可更新视图：把虚拟表当真表写

前置知识#

• 视图与物化视图的基本概念（视图与物化视图）——本篇回答视图的最后一问：“它能不能写？”

问题引入：视图的安全门与写入的两难#

视图的经典用途是安全门：给运营岗一个只看在职员工的视图，不给底层表权限。但现实业务马上追问：运营能不能通过这个视图给新员工建档、给在职员工调薪？如果视图只读，权限模型就裂成了”读走视图、写走底表”两套。

PostgreSQL 的答案分三级，按视图复杂度自动升级：

一级：自动可更新   简单视图，INSERT/UPDATE/DELETE 直接能用
二级：WITH CHECK OPTION   给自动可更新加"不许写漏网行"的约束
三级：INSTEAD OF 触发器   复杂视图，写入行为由你接管编程

一级：自动可更新视图#

对”足够简单”的视图，PostgreSQL 自动把写入翻译回底层表：

CREATE VIEW active_employees AS
SELECT id, name, salary, dept_id
FROM employees
WHERE status = 'active';

-- 读写全部直接可用，无需任何额外定义
INSERT INTO active_employees (name, salary, dept_id)
VALUES ('小明', 8000, 3);

UPDATE active_employees SET salary = 9000 WHERE name = '小明';
DELETE FROM active_employees WHERE id = 42;

“足够简单”的精确条件（缺一不可）：

• 只引用一张表（或另一个自动可更新视图）；
• 不含聚合、窗口函数、GROUP BY、HAVING、DISTINCT、集合操作（UNION 等）；
• SELECT 列是列的直接引用，不允许表达式或函数包装。

满足条件的判定有个快捷自检：information_schema.views.is_updatable 列直接告诉你 YES/NO。

一个必须知道的语义细节：视图带 WHERE 过滤时，UPDATE/DELETE 只作用于过滤后的可见行，但 INSERT 进来的行不受过滤约束——通过 active_employees 视图完全可以插入一条 status=‘inactive’ 的员工，它从此在视图里”隐身”但真实存在。这个漏洞就是二级存在的理由。

二级：WITH CHECK OPTION 堵住漏网行#

CREATE VIEW active_employees AS
SELECT id, name, salary, dept_id
FROM employees
WHERE status = 'active'
WITH CHECK OPTION;

-- 漏网写入被拒：
INSERT INTO active_employees (name, salary, dept_id, status)
VALUES ('张三', 8000, 3, 'inactive');
-- ERROR: new row violates check option of view "active_employees"

UPDATE active_employees SET status = 'inactive' WHERE id = 7;
-- 同样被拒：更新后的行不再满足视图条件

WITH CHECK OPTION 的语义一句话：通过视图写入的每一行，写完之后必须仍然能从这个视图里被看到。它把视图从”过滤窗口”升级为”业务规则守卫”——配合权限体系（把底表权限全部收回、只授视图），“在职员工表”的不变式就从应用层纪律变成了数据库层强制（纵深防御思路与 RLS 一脉相承）。

三级：INSTEAD OF 触发器接管复杂视图#

JOIN、聚合类视图天然不可自动更新（一行视图数据对应多行底表，引擎无从猜你的意图），这时 INSTEAD OF 触发器让你亲手定义写入的翻译：

-- JOIN 视图：员工详情（员工表 + 部门表）
CREATE VIEW employee_details AS
SELECT e.id, e.name, e.salary, d.dept_name
FROM employees e JOIN departments d ON e.dept_id = d.id;

-- 定义"对视图的 UPDATE 应该做什么"
CREATE OR REPLACE FUNCTION trg_upd_employee_details()
RETURNS trigger AS $$
BEGIN
  UPDATE employees SET name = NEW.name, salary = NEW.salary
  WHERE id = NEW.id;                 -- 把视图行翻译回底表更新
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER upd_employee_details
INSTEAD OF UPDATE ON employee_details
FOR EACH ROW EXECUTE FUNCTION trg_upd_employee_details();

-- 之后视图的 UPDATE 被"劫持"为函数里的逻辑
UPDATE employee_details SET salary = 12000 WHERE id = 7;

INSTEAD OF 的字面意思就是”代替”：数据库本来要执行的（对视图的写入，不可能执行）被你的函数完全替代。可以分别定义 INSERT/UPDATE/DELETE 三种触发器，各自翻译。设计要点：触发器函数里做输入校验（比如禁止跨部门转移时改薪资），错误用 RAISE EXCEPTION 抛出回滚——它是复杂视图写入的最终守门人。

动手环节：三级能力逐级体验#

-- 1. 确认可更新性
CREATE TABLE emp_demo (id serial PRIMARY KEY, name text, status text);
CREATE VIEW v_active AS SELECT * FROM emp_demo WHERE status = 'active';
SELECT is_updatable FROM information_schema.views
WHERE view_name = 'v_active';    -- YES

-- 2. 三种写入全通过
INSERT INTO v_active (name, status) VALUES ('a1', 'active');
UPDATE v_active SET name = 'a1x' WHERE name = 'a1';

-- 3. 复现"漏网行"漏洞
INSERT INTO v_active (name, status) VALUES ('ghost', 'inactive');  -- 成功！
SELECT * FROM v_active WHERE name = 'ghost';   -- 看不到
SELECT * FROM emp_demo  WHERE name = 'ghost';  -- 却真实存在

-- 4. CHECK OPTION 封堵
CREATE OR REPLACE VIEW v_active AS
SELECT * FROM emp_demo WHERE status = 'active'
WITH CHECK OPTION;
INSERT INTO v_active (name, status) VALUES ('ghost2', 'inactive');  -- 报错

-- 5. INSTEAD OF 体验（用 JOIN 视图）
CREATE TABLE dept_demo (id int PRIMARY KEY, dname text);
INSERT INTO dept_demo VALUES (1, '研发');
CREATE VIEW v_full AS
SELECT e.id, e.name, d.dname FROM emp_demo e
JOIN dept_demo d ON e.id = d.id;   -- 示意性 JOIN 键，实际按业务外键
-- 按上文模板挂 INSTEAD OF UPDATE 触发器后测试写入

第 3 步的 ghost 行值得认真玩味：没有 CHECK OPTION 的可更新视图是一个安静的坑——数据写进去了，视图里却永远看不见，排查这类”幽灵数据”的时耗远大于当初加上两个单词的成本。

常见困惑#

“物化视图能更新吗？“——不能（它物化的是查询结果的快照，刷新靠 REFRESH MATERIALIZED VIEW）。这与”可更新视图”是两个正交概念：普通视图不存数据但可写，物化视图存数据但只读。

“INSTEAD OF 触发器和普通 AFTER 触发器什么区别？“——AFTER 触发器是”做完之后追加动作”，作用于真实表；INSTEAD OF 是”本来要做的事取消，换成我做”，只能建在视图上。两者语法相似，语义完全不同。

“该用视图写入还是直接写表？“——业务简单直接写表；需要权限收敛或业务不变式时用”视图 + CHECK OPTION + 收回底表权限”；多表联合的复杂写入语义用 INSTEAD OF，但要警惕触发器里藏业务逻辑带来的可维护性成本——逻辑复杂到一定程度的更优解是应用层服务或存储过程显式封装。

检验清单#

• 能默写自动可更新视图的三个条件，并用 is_updatable 自检；
• 亲历过”漏网行”现象并能解释 WITH CHECK OPTION 的语义；
• 会写 INSTEAD OF 触发器接管 JOIN 视图的 UPDATE，并知道用 RAISE EXCEPTION 做校验；
• 能说清可更新视图与物化视图在”可写性”上的正交关系。

下一步#

视图解决”数据的组织”，生成列 解决”数据的派生”——两者常在同一张表的设计里配合出场。