含外键的页面编辑最佳实践：全量提交还是仅提交差异？

一、两种更新策略的优劣对比 #

1. 全量发送所有属性 #

这种方案下，不管用户改了什么，前端都把Post的所有字段（title、description、完整tags列表）一起发给后端。

• 优势：
  • 后端逻辑极简：直接用新数据覆盖旧数据——title和description直接更新，tags则先清空Post与Tags的关联，再插入新的关联关系，不用做任何差异计算，代码好写也好维护，出错概率低。
  • 前端实现简单：不用管什么差异对比，编辑完表单直接把当前的所有数据发出去就行，省了维护原始状态、计算变化的功夫。
  • 数据一致性有保障：避免前端差异计算错误导致的后端数据混乱，比如漏发某个字段的修改。
• 劣势：
  • 数据冗余：哪怕只删了一个标签，也要把title、description这些没改的字段一起发，要是description是长文本，网络传输量会没必要地增大。
  • 数据库额外开销：标签关联需要全删全插，标签多的时候，数据库IO成本会变高。

2. 仅发送差异数据 #

这种方案下，前端只发变化的部分，比如只删了"frontend"标签，就发{removedTags: ["frontend"], addedTags: []}，如果同时改了title，就加上title: "Updated title"。

• 优势：
  • 网络传输高效：只传变化的内容，数据量小，在移动网络或者弱网环境下体验更好。
  • 数据库操作更高效：标签只删要移除的、加新增的，不用全删全插，减少数据库压力。
• 劣势：
  • 前端复杂度上升：得维护原始数据和修改后的数据，计算出哪些字段改了、标签是增了还是删了，开发和测试成本都更高。
  • 后端要处理多场景：得区分普通字段更新和标签的增删，还要考虑并发问题（比如用户编辑时，其他人改了这个Post的数据）。
  • 调试难度大：要是差异计算错了，定位问题比全量更新麻烦得多。

二、行业常用方案 #

不同场景会有不同选择：

• 中小系统/快速迭代项目：优先选全量发送，因为开发快、维护简单，数据量不大的情况下，网络和数据库的损耗完全可以接受，能快速上线功能。
• 大规模系统/高并发场景/移动端：会用差异更新，尤其是当Post内容字段大、标签频繁变动时，能显著降低网络和数据库开销。还有些系统会同时提供两种接口，让前端根据情况选。
• 折中方案：前端只发修改过的字段（包括当前完整的tags列表），比如只改了标签就发{tags: ["database", "backend"]}，改了title加标签就发{title: "Updated title", tags: ["database", "backend"]}。这种方式前端不用算标签的增删，后端可以对比新旧标签列表来做增量操作，兼顾了简单性和效率。

三、相关主题名称及参考资料 #

• 核心主题：RESTful API更新策略、部分更新（Partial Update）、关联数据增量更新、多对多关系更新优化
• 参考资料：
  • 《RESTful Web APIs》中关于PUT（全量更新）与PATCH（部分更新）的适用场景分析，明确两种HTTP方法在资源更新中的定位。
  • 数据库多对多关系更新最佳实践：重点关注批量操作、事务处理、索引优化等内容，减少关联更新的数据库开销。
  • 前端状态管理指南：比如React、Vue框架中，如何维护表单的原始状态与修改状态，实现高效的差异提交逻辑。

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