审核Db行中更改的历史记录

本文关键字：历史 记录 Db 审核 | 更新日期: 2023-09-27 18:05:11

场景：

我有一个数据库表，为了进行比较，需要对该表任何列的数据进行任何更改进行审计记录。

我尝试过的：

我有一个历史表，它的值列与父表相同，对数据库的任何更改都会使用触发器记录到新表中，我最终实现了我想要的。

问题

问题是多方面的：

  • 我正在使用我不想使用的触发器
  • 如果我必须对n个以上的表进行审计比较，那么我需要每个父表有一个历史表，这只会使我的数据库膨胀，并使其庞大，因为有这么多表

有没有更好的方法来实现这一点，请提出建议？

审核Db行中更改的历史记录

答案与业务或域逻辑所在的位置密切相关。

如果您的业务逻辑在数据库(stored procedures和triggers(中，那么我认为让数据库triggers写入相关审计表是正确的。

我正在使用我不想使用的触发器。

审计应用程序：

如果您的域逻辑在c#代码中的域层中，那么您说不希望审计在triggers中是非常正确的。在域层和数据库之间混合业务逻辑可能会导致维护噩梦o_o

假设您的逻辑位于域层：一个想法是为您的域或服务提供一个base class，用于处理向审计跟踪的写入：

public class DomainBase<T>
{
    public DomainBase(bool isAuditEnabled)
    {
        this.IsAuditEnabled = isAuditEnabled;
    }
    public bool IsAuditEnabled { get; set; }
    public void AddNew(T newEntity)
    {
        // default code for adding an entity
        this.Audit_Create(newEntity);
    }
    public void Audit_Create(T newEntity)
    {
        if (IsAuditEnabled)
        {
            // ...
        }
    }
}

您的base class可以具有标准的AddNew、Update和Delete方法，这些方法依次调用相关的Audit方法。然后，您可能还想考虑使用IsAuditEnabled开关，以便轻松打开/关闭特定审核。这样，您只审核您关心的更改，而不审核其他更改。

每个自定义域方法都可以选择是否写入审计跟踪。这也是为什么在您的场景中，将审计跟踪放在DAL(数据访问层(中不是一个好主意，因为业务逻辑决定是否和必须审计，DAL不应该做出这些类型的逻辑决定。

如果我必须对另外n个表进行审计比较，那么我需要每个父表都有一个历史记录表，这让我的数据库，并使其庞大，有这么多表。

数据库问题的大小

  1. 如前所述，只审核您需要的内容将减少已写入审计数据
  2. 如果审核数据过多或增长过快，您可以选择单独的审核数据库。这样，您的生产数据库保持轻量级和优化，并且您只能在罕见的情况下(希望(查询审计数据库。通过这种方式，您可以执行BIG并在不考虑性能的情况下审计所有移动的生命周期(甚至不在审计数据库中包括indexes，以实现快速高效的写入(
  3. 此外，如果您并不真正关心表中的所有数据，则可以创建只包含重要字段的审核表。因此，您最终可能会得到一个由50列组成的表，只审核5或10列，这些列对于历史目的至关重要
相关文章：