数据库中应跟踪完整修订版本还是修订差异？

问题背景 #

为foo表的some_text_column字段做审计跟踪，每次执行UPDATE操作时向foo_history表插入记录，纠结是保存字段的完整原始内容还是仅保存变更差异（Diff）。

举例：

• 完整内容存储：直接存入更新前的值'abc'
• Diff存储：以类似格式记录变更

  - abc
  + def
  

已知短字符串Diff占用空间更大，但长字符串仅修改少量内容时Diff更省空间，同时疑惑数据库对冗余数据的优化是否让完整存储更可行。

专业建议：优先选完整内容存储，特殊场景再考虑Diff #

1. 查询与追溯的便捷性 #

• 完整内容存储无需额外计算，直接就能查看某一版本的完整字段值，排查问题、核对历史时效率极高。比如要确认某时间点字段的状态，直接查foo_history就能拿到，不需要把Diff逐个合并还原。
• Diff存储需要额外的还原逻辑，无论是在应用层还是数据库层处理，都会增加查询复杂度，尤其是跨多个版本追溯时，合并Diff的成本会线性上升。

2. 存储成本的实际影响 #

• 现代数据库对重复数据有成熟的压缩优化（比如PostgreSQL的TOAST压缩、MySQL的行压缩），即使存储大量重复的完整文本，实际占用的磁盘空间并没有想象中那么大。
• 只有当字段是超大文本（几十KB以上）且变更频率极高、每次仅修改极小部分时，Diff的存储优势才会凸显。普通长度的字段，完整存储的空间成本可以忽略。

3. 维护复杂度 #

• 完整存储的触发器逻辑非常简单：更新前直接把旧值插入历史表即可，几乎没有出错风险。
• Diff存储需要在触发器中计算新旧值的差异，这会增加触发器复杂度，而且不同数据库实现Diff的方式不同（比如要自定义函数），后续维护、迁移都更麻烦。

4. 业务扩展性 #

• 完整存储的历史表兼容性更强，后续扩展审计字段或调整业务逻辑时，历史数据的可用性不受影响。
• Diff存储如果后续需要查看完整历史版本，就得额外开发还原工具，甚至可能因为早期Diff格式不兼容导致数据无法还原。

适合用Diff存储的场景 #

如果满足以下所有条件，可以考虑Diff：

• 字段是超大文本类型（比如长文章、配置文件）
• 每次变更仅修改极小部分内容（比如改一个标点、替换几个词）
• 存储资源极其紧张，且已经通过数据库压缩等手段优化过完整存储的成本

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