PostgreSQL如何实现级联软删除？是否有更优方案？

不是只能通过触发器实现，触发器是最常用且可靠的方案之一，但还有几种更简洁易维护的方式可以选择，以下是具体方案：

1. 通用化触发器（推荐） #

不用为每个子表单独编写触发器函数，而是封装一个通用的软删除级联函数，复用在所有需要级联的父表上，大幅降低维护成本。

示例代码：

-- 创建通用的软删除级联函数
CREATE OR REPLACE FUNCTION cascade_soft_delete()
RETURNS TRIGGER AS $$
BEGIN
  -- 动态生成子表更新语句，TG_ARGV传递子表名和关联字段名
  EXECUTE format(
    'UPDATE %I SET is_deleted = TRUE WHERE %I = $1',
    TG_ARGV[0], TG_ARGV[1]
  ) USING OLD.id;
  RETURN OLD;
END;
$$ LANGUAGE plpgsql;

-- 给父表绑定触发器，指定子表和关联字段
CREATE TRIGGER trigger_users_soft_delete_cascade
AFTER UPDATE OF is_deleted ON users
FOR EACH ROW
WHEN (NEW.is_deleted = TRUE)
EXECUTE FUNCTION cascade_soft_delete('orders', 'user_id');

这种方式的优势是函数可复用，新增子表时只需添加一条触发器语句即可，逻辑清晰且易于维护。

2. 视图+INSTEAD OF触发器 #

通过创建包含父表和子表的视图，将软删除操作统一到视图层面，用户只需更新视图的is_deleted标记，触发器自动同步更新底层的父表和子表。

示例代码：

-- 创建包含用户和订单的视图
CREATE VIEW users_with_orders AS
SELECT u.id AS user_id, u.name, u.is_deleted AS user_deleted,
       o.id AS order_id, o.amount, o.is_deleted AS order_deleted
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

-- 创建视图的软删除处理函数
CREATE OR REPLACE FUNCTION soft_delete_user_with_orders()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.user_deleted = TRUE THEN
    UPDATE users SET is_deleted = TRUE WHERE id = NEW.user_id;
    UPDATE orders SET is_deleted = TRUE WHERE user_id = NEW.user_id;
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- 给视图绑定INSTEAD OF触发器
CREATE TRIGGER trigger_users_with_orders_soft_delete
INSTEAD OF UPDATE OF user_deleted ON users_with_orders
FOR EACH ROW
EXECUTE FUNCTION soft_delete_user_with_orders();

适合所有操作都通过视图进行的场景，对外屏蔽底层表的复杂关联逻辑，但需要确保视图覆盖所有必要的业务操作。

3. 应用层统一处理 #

如果业务架构允许，在应用代码中封装软删除的通用方法，当执行父表软删除时，自动触发所有关联子表的软删除操作。比如用ORM框架的信号/钩子机制，或者编写通用的工具函数。

示例伪代码（Python+SQLAlchemy）：

def soft_delete(model_instance):
    # 标记当前实例为已删除
    model_instance.is_deleted = True
    db.session.add(model_instance)
    
    # 处理关联子表
    if hasattr(model_instance, 'orders'):
        for order in model_instance.orders:
            order.is_deleted = True
            db.session.add(order)
    
    db.session.commit()

这种方式不需要修改数据库结构，逻辑完全在应用层可控，适合小型项目或应用架构统一的场景，但依赖应用层的代码规范，需要确保所有软删除操作都通过该方法执行。

4. 使用SQL规则（RULE） #

PostgreSQL的RULE可以重写SQL语句，将父表的软删除操作自动扩展为包含子表的更新。不过RULE的逻辑相对复杂，容易在复杂查询场景下出现意外行为，一般仅作为备选方案。

示例代码：

CREATE RULE rule_users_soft_delete_cascade AS
ON UPDATE TO users
WHERE NEW.is_deleted = TRUE
DO ALSO
UPDATE orders SET is_deleted = TRUE WHERE user_id = OLD.id;

总结 #

• 通用触发器是数据库层面最可靠、易维护的方案，适合大多数场景；
• 应用层处理适合业务逻辑集中管理的场景，降低数据库复杂度；
• 视图+触发器和RULE可作为补充方案，根据实际业务需求选择。

内容的提问来源于stack exchange，提问作者juztcode