|
我们计划在数据库中引入简单的审计跟踪,使用触发器和需要审计的单独历史表。. c$ q& ^' g. E/ r) n( s4 p
例如考虑表StudentScore,它只有很少的外键(例如StudentID,CourseID)将其链接到相应的父表中(Student&Course)。: J# F8 x# H6 ?- {/ J& s2 t
Table StudentScore StudentScoreID,-- PK StudentID ref Student(StudentID), -- FK to Student CourseID ref Course(CourseID), -- FK to Course)如果StudentScore需要审核,我们计划创建审核表StudentScoreHistory-/ ~( G. _) m6 V, i x' c! t/ R) |
Table StudentScoreHistory ( StudentScoreHistoryID,-- PK StudentScoreID, StudentID, CourseID, AuditActionCode, AuditDateTime, AuditActionUserID)如果修改了StudentScore任何一行,我们都会把旧行移到StudentScoreHistory。4 k" z, J1 H. I9 Q" _* }
在设计讨论中提出的观点之一是StudentHistory表中的StudentID和CourseID设置为FK,保持参考完整性。支持这一点的原因是我们
. s1 x+ I; d8 Q, I6 l6 Z通常总是 删除软(逻辑布尔标志)而不是硬删除,有利于保持引用的完整性,以确保我们在审计表中没有孤立ID。2 S. ?( E( Q& [% X& v& Q5 \
Table StudentScoreHistory StudentScoreHistoryID,-- PK StudentScoreID, StudentID ref Student(StudentID),-- FK to Student CourseID ref Course(CourseID),-- FK to Course AuditActionCode, AuditDateTime, AuditActionUserID)这对我来说似乎有点奇怪。我真的同意了@Jonathan
2 W# B1 y7 c; L: uLeffler评论,即审计记录不应阻止删除父亲的数据。相反,如有必要,应通过主表中的外键而不是审计表中的外键进行处理。我想征求你的意见,以确保外键在扩展到审计表时不会失去任何价值。" m; C4 h6 C! U" n7 l7 \; e
现在我的问题是: 这些外键是否包含在历史记录表中是一个很好的设计?
3 D+ Y( K% S6 A$ O ]我们将感谢任何关键论点的细节(如性能、最佳实践、设计灵活性等)。9 }8 |2 ^, T, f& t
任何寻求特定目的和我们环境的人的利益:
4 p: i! k7 H# j& T目的:, P1 h3 D3 d. s7 B# I3 ]! n
[ol]维护关键数据历史
+ w/ V* F0 g5 t8 S' G8 G允许审查用户活动并支持重建计划
5 o8 [# O, c" k; P6 i+ F在一定程度上允许回滚用户活动[/ol]环境:/ [0 R+ \: u" w
交易数据库
+ Z; c, G7 f! f并不是每个表都需要审核
" K/ t' h; ]. {1 j- Q# s6 r尽量使用软删除,特别是静态/参考数据( _2 F9 S; \5 [
很少有高度事务性的表使用硬删除
# A2 ?. |& H3 M3 c6 {3 R# g" R0 l 解决方案: |
|