对SQL数据库中的数据进行修订控制的最佳做法

我的整个数据库偶尔会有错误的条目，但不是直接更改数据，而是希望能够对修改进行修改。对SQL数据库中的数据进行修订控制的最佳做法

这些更改很少发生。

理想情况下是这样的： -

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

所以说，我有一个表叫帖子下面的模式： -

title | description | timestamp | author

一个额外的表称为posts_revisions将被创建因此： -

title | description | timestamp | author | revision_version | origin | user | timestamp

原点是变化的来源，无论是机器人，用户生成还是你有什么。

正如你可以想象这是对现有数据库的一个相当大的改变，我目前关心的是检查每个查询的_revisions表的性能。这是这种事情的最佳做法吗？

来源

2012-08-02 martin blank

不要害怕在两个表中复制原点，用户和时间戳。您可能想要删除后台作业中的修订。删除所有帖子不存在的修订。理论上，你甚至可以懒惰地创建日志挖掘的修订。更大的交易和更低的摊销成本。 – 2012-08-02 13:00:06

对于这种类型的问题，我保留当前表和历史表。

历史表具有以下附加列：

HistoryID
EFFECTIVEDATE
结束日期
VERSIONNUMBER
CreatedBy
CreatedAt

生效日期和结束日期是值有效的时间跨度。每次记录更改时，版本都会增加。 id，CreatedAt和CreatedBy是我放入数据库几乎每个表中的列。

通常，我会将历史记录表与最新的夜间作业保持一致，即比较表格，然后使用MERGE合并数据。另一种方法是将所有更改包装在存储过程中，并在那里更新两个表。另一种选择是使用触发器，它可以检测到更改发生的时间。但是，我避开触发器，宁愿选择前两种。

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

此方法的一个缺点是更改基表的结构。如果您想添加一列，则需要将其添加到历史记录表以及基表中。

来源

2012-08-02 13:52:28

如果这些表格用于摘要目的（尤其是业务用户，如果他们有一些SQL访问权限）我认为最好删除数据并将其放入另一个表中。虽然标志和修订有时很好，但当你必须沿着select sum(select someVar where revision_version=max(revision_version and someID=ID))的方向做某件事时，它确实会超越简单。

如果您有一张用于快速收集数据的表格，请将数据替换，并根据需要将旧数据放入修订表格中。如果只有某些应用程序会访问它并且它不是性能问题然后将其保留在主表中。

来源

2012-08-02 12:57:46 Fluffeh

对SQL数据库中的数据进行修订控制的最佳做法

回答

相关问题