SQL数据库中数据修订控制的最佳实践

时间:2012-08-02 12:51:39

标签: mysql sql postgresql

我的整个数据库偶尔会有错误的条目,但我不想直接更改数据,而是希望能够保留修改的更改。

这些变化很少发生。

理想情况如下: -

 (original table fields) | revision_version | origin | user | timestamp

所以说我有一个名为帖子的表格,其中包含以下架构: -

title | description | timestamp | author

因此将创建一个名为 posts_revisions 的附加表: -

title | description | timestamp | author | revision_version | origin | user | timestamp
  • 原产地是变更的来源,无论是机器人,用户生成的还是您拥有的。

您可以想象这是对现有数据库的一个相当大的更改,我目前关注的是检查每个查询的_revisions表的性能损失。对于这种事情,这是最好的做法吗?

2 个答案:

答案 0 :(得分:2)

对于这类问题,我保留了当前表和历史表。

历史记录表包含以下附加列:

  • HistoryID
  • EFFECTIVEDATE
  • 结束日期
  • VERSIONNUMBER
  • CreatedBy
  • CreatedAt

有效日期和结束日期是值有效的时间跨度。每当记录发生变化时,版本就会增加。 id,CreatedAt和CreatedBy是我几乎放入数据库中每个表的列。

通常,我会将历史记录表与夜间作业保持同步,比较表格,然后使用MERGE组合数据。另一种方法是将所有更改包装在存储过程中,并在那里更新两个表。另一种方法是使用触发器来检测何时发生更改。但是,我回避了触发器,更喜欢前两种选择。

我必须承认磁盘空间不是这些表的重要考虑因素。因此,存储数据两次没有问题,一次在历史记录中的结果中一次。这只是一个小调整,只在历史表中存储历史记录,当前记录在“当前”表中。

这种方法的一个缺点是改变了基表的结构。如果要添加列,则需要将其添加到历史记录表和基表中。

答案 1 :(得分:1)

如果这些表用于汇总目的(特别是业务用户,如果他们有一些SQL访问权限),我认为最好删除数据并将其放入另一个表中。虽然标志和修订有时很好,但是当你必须按照select sum(select someVar where revision_version=max(revision_version and someID=ID))的方式做某事时,它确实超出了简单的范围。

如果您有一个用于快速和讨厌的数据收集的表,请替换数据,如果需要,将旧数据放入修订表。如果只有一些应用程序将访问而且这不是性能问题,那么请将其保存在主表中。