【发布时间】：2012-09-07 15:33:39
【问题描述】：
我正在寻找一个合适的过程来在数据库中保存修订或行（及其关系）的快照。
以电子商务平台为例-
- 客户创建订单。订单与帐单地址和送货地址相关联。
- 然后，该客户在其个人资料中更改了地址簿中的地址。
- 原始订单的地址不应更改。
我查看了一些概念，一个是重复表，另一个是临时数据库，另一个是保留修订 ID 和活动标志。
虽然我很感激没有人能真正告诉我最适合我的应用程序的解决方案，因为这是一个值得商榷的问题等，但我希望有人能够通过比较来证明优点/缺点。我已经阅读了很多关于 SO 的问题，以及一些关于各种实现的文章，但没有人真正比较每个想法或指出它们最适合的地方。下面我概述了我对每个概念的理解。
重复表
将信息存储在与需要与之生成快照的数据相关的行中。 IE。在在线商店的订单表的列中保留地址。
优势
- 数据被分割成明确相关的表，不需要连接等。
- 无需按照以下概念的要求仅选择活动行。
- 假设行带有时间戳，则保留时态数据库的大部分优势
缺点
- 复制
- 架构的（特别是在多个表向上修订时会出现问题）
- 使用 ORM 时的模型。
- 的数据，如果快照片段数据未更改且已重复使用。 IE。如果下单10次，地址存储11次（订单+当前）
- 处理插入到相关表中需要额外的代码。
临时数据库/活动或当前行标志
“时间感知”的数据库行，即它们的上下文是两个日期时间之间的时间。数据可以在其时间上下文位于时态表之间的位置进行连接。
优势
- 没有重复的模式或模型。在一处进行的更改。
- ORM 模型可以无缝处理新行的创建、标记为活动等。
- 不复制未进行更改的行。 IE。 10个订单到1个地址一次存储地址。
缺点
- 查询变得更加复杂，因为连接/where 子句需要选择“活动”行。
- 表格被未定期选择/调用的历史数据堵塞。
只存储更改的列，临时的。
有一个表格来跟踪所有表格的更改，并注意它所涉及的行以及它在时间方面的有效时间。
优势
- 在修订方面优化了存储，因为未复制未更改的数据。
缺点
- 将列的版本与其他数据结合起来的查询要复杂得多。
我已经在这里查看了关于 SO 的以下问题，以及这些其他资源
编辑：我没有用特定的 DBMS 标记这篇文章的原因是我希望这个概念可以与尽可能多的平台一起使用，目前是独立于 DBMS 的，抽象层允许它工作与 MySQL 和 MSSQL，但希望在未来支持其他人。
- Database Design for Revisions?
- Relational Schema for Fowler's Temporal Expressions
- Database design for text revisions
- Storing Revisions of Relational Objects in an Efficient Way
- Keeping page changes history. A bit like SO does for revisions
- maintain history in a database
- http://en.wikipedia.org/wiki/Temporal_database
- http://www.simple-talk.com/sql/database-administration/database-design-a-point-in-time-architecture/
【问题讨论】：
标签： database temporal-database