我正在寻找一个合适的过程来保存数据库中行（及其关系）的修订或快照。
以电子商务平台为例-
- 客户创建订单。订单与帐单地址和送货地址相关联。
- 所述客户然后在他们的个人资料中更改他们的地址簿中的地址。
- 原始订单的地址不应更改。
我看过一些概念，一个是重复表，另一个是临时数据库，另一个是保留修订 ID 和活动标志。
虽然我很感激没有人能真正告诉我最好/最适合我的应用程序的解决方案，因为这是一个开放的意见等问题，我希望有人能够通过比较来证明优点/缺点。我已经阅读了很多关于 SO 的问题，以及一些关于各种实现的文章，但没有人真正比较每个想法或指出它们最适合的地方。下面我概述了我对每个概念的理解。
重复表
将信息存储在与需要与之生成快照的数据相关的行中。即在在线商店的订单表的列中保留地址。
好处
- 数据被分割成明确相关的表，不需要连接等。
- 无需按照以下概念的要求仅选择活动行。
- 假设行带有时间戳，则保留时态数据库的大部分好处
缺点
- 复制
- 模式（当多个表向上修订时特别有问题）
- 使用 ORM 时的模型。
- 如果快照片段数据没有更改并且被重用，则数据的数量。即下单10次，地址存储11次（订单+当前）
- 处理插入相关表所需的额外代码。
时态数据库/活动或当前行标志
“时间感知”的数据库行，即它们的上下文是两个日期时间之间的时间。可以在时间上下文位于时态表之间的位置连接数据。
好处
- 没有模式或模型的重复。在一处进行的更改。
- ORM 模型可以无缝地处理新行的创建、标记为活动等。
- 不复制未进行更改的行。即 10 个订单到 1 个地址存储一次地址。
缺点
- 查询变得更加复杂，因为连接/where 子句需要选择“活动”行。
- 表格被未定期选择/调用的历史数据堵塞。
仅存储更改的列，时间。
有一个表来跟踪所有表的更改，并注意它所涉及的行以及它在时间方面何时有效。
好处
- 在修订方面优化存储，因为未复制未复制的未更改数据。
缺点
- 将列的版本与其他数据结合起来的查询要复杂得多。
我已经在 SO 上查看了以下问题，以及这些其他资源
编辑：我没有用特定的 DBMS 标记这篇文章的原因是我希望这个概念尽可能多地与平台一起工作，目前是 DBMS 独立的，抽象层允许它与 MySQL 和MSSQL，但希望将来会支持其他人。