PostgreSQL嵌套简历数据更新：删除重插vs差异更新哪种更优？

我正在用FastAPI + PostgreSQL（Supabase）开发简历生成应用，数据规范化存储在多张表中：

personal_info
locations
skills
experience
education
projects
certifications
technical_participation
co_curricular
extra_curricular
achievements

每张表都包含user_id外键。用户点击「保存」时，前端会发送完整的简历JSON结构：

{
  "personal_info": { ... },
  "skills": [...],
  "experience": [...],
  "education": [...],
  "projects": [...],
  "certifications": [...],
  "technical_participation": [...],
  "co_curricular": [...],
  "extra_curricular": [...],
  "achievements": [...]
}

用户保存前可进行的修改操作包括：

• 更新现有经历条目
• 删除经历条目
• 新增经历条目
• 调整条目顺序
• 更新技能
• 移除证书
• 新增项目
• 其他任意组合的修改

我目前考虑两种更新方案：

方案1：替换整个简历 #

在单个事务内执行以下步骤：

1. 更新personal_info表
2. 删除该用户所有子表（experience、education等）的记录
3. 重新插入传入JSON中的所有数据

示例SQL：

BEGIN;

DELETE FROM experience WHERE user_id = ?;
DELETE FROM education WHERE user_id = ?;
DELETE FROM projects WHERE user_id = ?;

INSERT INTO experience (...);
INSERT INTO education (...);
INSERT INTO projects (...);

COMMIT;

优点 #

• 实现简单，开发成本低
• 自动处理增删改所有操作，无需额外判断

缺点 #

• 每次保存都会重建所有子表记录
• 记录主键会频繁变更
• 无法追踪单个记录的修改历史

方案2：差异更新 #

为每个子表记录分配独立UUID并返回给前端，前端后续提交的JSON中会携带这些ID：

{
  "experience": [
    {
      "id": "uuid-1",
      "company": "Google"
    },
    {
      "id": "uuid-2",
      "company": "Microsoft"
    }
  ]
}

后端处理逻辑：

• 对带ID的记录执行更新操作
• 对无ID的记录执行插入操作
• 删除数据库中存在但请求JSON里缺失的记录

优点 #

• 保留记录的唯一标识，主键稳定
• 便于实现审计和历史版本追踪
• 仅修改变更的记录，效率更高

缺点 #

• 实现复杂度显著提升，需要处理ID匹配、差异对比等逻辑

问题解答 #

业界通用方案 #

对于前端始终提交完整简历JSON的场景，两种方案都有实际应用，核心选择依据是你的业务优先级：

• 如果快速上线、低开发成本是首要目标，删除重插（方案1）是中小项目的常见选择，尤其简历这类数据量极小的场景（单用户子表记录数通常不超过几十条）。
• 如果需要审计追踪、记录稳定性，或未来可能扩展多端协作、版本管理功能，差异更新（方案2）是更专业的长期方案。

删除重插是否可行？ #

完全可行，尤其针对简历应用的场景：

• 性能层面：单用户子表记录数极少，删除+插入的开销可以忽略，PostgreSQL处理这类小事务毫无压力。
• 完整性层面：只要包裹在单个事务中，就能保证数据一致性，不会出现部分删除、部分插入的异常情况。
• 维护层面：代码逻辑简单，后续维护成本低，不容易出现边界bug（比如漏处理某些类型的变更）。

唯一需要注意：如果未来业务需要基于单个记录做跨模块关联（比如某个项目被其他功能引用），主键频繁变更会带来问题，但简历应用通常不存在这类场景。

哪种方案更优？ #

没有绝对最优解，取决于你的优先级：

1. 优先快速落地：选方案1，开发快、bug少，完全满足简历应用的基本需求。
2. 优先长期扩展性：选方案2，虽初期开发麻烦，但能支撑后续的版本历史、审计日志、多端同步等功能。
3. 折中方案：若担心未来扩展，可先按方案1开发，同时在子表中预留UUID字段，后续需要时再切换到差异更新逻辑——因简历数据量小，迁移成本极低。

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