我们计划使用触发器和需要审计的每个表的单独历史表在数据库中引入简单的审计跟踪。

例如考虑表StudentScore，它只有很少的外键（例如StudentID，CourseID）将其链接到相应的父表（Student＆Course）。

Table StudentScore (
    StudentScoreID, -- PK
    StudentID ref Student(StudentID),  -- FK to Student
    CourseID ref Course(CourseID),   -- FK to Course
)

如果StudentScore需要审核，我们计划创建审核表StudentScoreHistory-

Table StudentScoreHistory (
    StudentScoreHistoryID, -- PK
    StudentScoreID,
    StudentID,
    CourseID,
    AuditActionCode,
    AuditDateTime,
    AuditActionUserID
)

如果修改了StudentScore中的任何行，我们会将旧行移至StudentScoreHistory。

在设计讨论中提出的观点之一是，将StudentHistory表中的StudentID和CourseID设置为FK，以保持参照完整性。支持这一点的理由是，我们
通常总是 进行软（逻辑布尔标志）删除而不是硬删除，这有利于保持引用完整性，以确保我们在审计表中没有任何孤立的ID。

Table StudentScoreHistory (
    StudentScoreHistoryID, -- PK
    StudentScoreID,
    StudentID ref Student(StudentID), -- FK to Student
    CourseID ref Course(CourseID), -- FK to Course
    AuditActionCode,
    AuditDateTime,
    AuditActionUserID
)

对我来说，这似乎有些奇怪。我确实同意@Jonathan
Leffler的评论，即审核记录不应阻止删除父数据。相反，如果需要，则应通过主表中的外键而不是审计表中的外键进行处理。我想征求您的意见，以确保在将外键扩展到审计表时不会丢失任何价值。

现在我的问题是： 在历史记录表中包含这些外键是否是一个好的设计？

我们将不胜感激有关关键论点的任何细节（例如性能，最佳实践，设计灵活性等）。

为了任何寻求特定目的和我们环境的人的利益：

目的：

1. 维护关键数据历史
2. 允许审核用户活动并支持重新创建方案
3. 在一定程度上允许回滚用户活动

环境：

• 交易数据库
• 并非每个表都需要审核
• 尽可能使用软删除，特别是用于静态/参考数据
• 很少有高度事务性的表使用硬删除