c# - Db 行更改的审计历史记录

Question

场景:

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

我尝试过的:

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

问题

问题是多方面的:

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

是否有更好的方法来实现这一目标，请提出建议？

Answer 1

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

如果您的业务逻辑在您的数据库中(存储过程 和触发器)，那么我觉得您的方法是让数据库触发器 code> 写入相关审计表。

I am using triggers which I do not want to use.

审计方法:

如果您的域逻辑位于c# 代码中的域层，那么您说您不希望审计位于触发器。在您的域层和数据库之间混合业务逻辑可能会导致维护噩梦o_O

假设您的逻辑位于域层:一个想法是为您的域或服务提供一个基类，以处理写入审计跟踪:

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)
        {
            // ...
        }
    }
}

您的基类可以有标准的AddNew、Update、Delete方法，这些方法依次调用相关的审计方法。然后，您可能还需要考虑一个 IsAuditEnabled 开关，以允许您轻松打开/关闭特定审核。这样您就可以仅审核您关心的更改，而无需审核其他内容。

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

If I have to have audit comparison for n more tables, then I need to have one history table per parent table and which just swells my database and makes it bulky with so many tables.

数据库关注的大小

1. 如前所述，仅审核您需要的内容会减少审计数据写入。
2. 如果审计数据过多或增长过快，您可以选择单独的审计数据库。这样您的生产数据库就会保持轻量级和优化，您只能在罕见情况下(希望如此)查询审计数据库。通过这种方式，您可以大并审计所有移动的生命，而不必担心性能(甚至不包括审计数据库中的索引以允许快速高效写)。
3. 此外，如果您并不真正关心表中的所有数据，您可以创建仅包含对您来说重要的字段的审计表。因此，您最终可能会得到一个包含 50 列的表格，仅审核 5 或 10 列，这些列对于历史目的至关重要。