为数据库应用程序留下审计跟踪/更改历史记录的有效策略？

Question

人们已经成功地采用了哪些策略来维护相当复杂的数据库中的数据更改历史记录。我经常使用和开发的应用程序之一确实可以从跟踪记录随时间变化的更全面的方法中受益。例如，现在记录可以有多个时间戳和修改的用户字段，但我们目前没有用于记录多个更改的方案，例如回滚操作时。在完美的世界中，可以在每次保存等之后重建记录。

有关数据库的一些信息：

• 需要具备每周增加数千条记录的能力
• 50-60桌
• 每个主修订表可能有几百万条记录
• 合理数量的外键和索引设置
• 使用 PostgreSQL 8.x

Answer 1

过去我使用触发器来构建数据库更新/插入/删除日志记录。

每次对特定表执行上述操作之一时，您都可以将记录插入到日志记录表中，该记录表跟踪操作、数据库用户执行的操作、时间戳、执行操作的表以及先前的值。

可能有一个更好的答案，因为我认为这需要您在执行实际删除或更新之前缓存该值。但你可以用它来进行回滚。

Answer 2

您可以使用的一种策略是 MVCC（多值并发控制）。在此方案中，您永远不会对任何表进行更新，您只需进行插入，维护每条记录的版本号。这样做的优点是可以提供任何时间点的精确快照，并且还可以完全避免困扰许多数据库的更新锁定问题。

但它会产生一个巨大的数据库，并且 select all 需要一个额外的子句来选择记录的当前版本。

Answer 3

如果您正在使用 Hibernate，请查看 杰博斯·恩弗斯. 。来自项目主页：

Envers 项目旨在实现持久 JPA 类的轻松版本控制。您所要做的就是使用 @Versioned 注释您想要版本控制的持久类或其某些属性。对于每个版本化实体，将创建一个表，该表将保存对该实体所做的更改的历史记录。然后，您可以毫不费力地检索和查询历史数据。

这有点类似于 埃里克的方法, ，但可能要少得多的努力。但不知道您使用什么语言/技术来访问数据库。

Answer 4

使用触发器的唯一问题是它会增加任何插入/更新/删除的性能开销。为了获得更高的可扩展性和性能，您希望将数据库事务保持在最低限度。通过触发器进行审核会增加执行交易所需的时间，并且根据交易量可能会导致性能问题。

另一种方法是探索数据库是否提供任何挖掘“重做”日志的方法，就像 Oracle 中的情况一样。重做日志是数据库在发生故障并必须恢复时用来重新创建数据的内容。

Answer 5

与触发器类似（甚至与触发器类似），您可以让每个事务异步触发日志记录事件，并让另一个进程（或只是线程）实际处理日志记录。根据您的应用程序，有多种方法可以实现这一点。我建议让应用程序触发该事件，以便它不会对您的第一个事务造成不必要的负载（有时会导致级联审核日志锁定）。

此外，您可以通过将审核数据库保留在单独的位置来提高主数据库的性能。

Answer 6

我使用 SQL Server，而不是 PostgreSQL，所以我不确定这是否适合您，但 Pop Rivett 有一篇关于创建审计跟踪的精彩文章：Pop Rivett 的 SQL Server 常见问题解答 No.5：审计追踪中的流行

构建一个审核表，然后为每个要审核的表创建一个触发器。

暗示：使用 码匠 建立你的触发器。