回答

收藏

保持参考完整性-好还是坏?

技术问答 技术问答 418 人阅读 | 0 人回复 | 2023-09-13

我们计划在数据库中引入简单的审计跟踪,使用触发器和需要审计的单独历史表。
- u' R6 e: g+ \" u) J例如考虑表StudentScore,它只有很少的外键(例如StudentID,CourseID)将其链接到相应的父表中(Student&Course)。
$ n) X" [! Z5 b6 r' F2 t0 t% f$ kTable StudentScore  StudentScoreID,-- PK    StudentID ref Student(StudentID), -- FK to Student    CourseID ref Course(CourseID),  -- FK to Course)如果StudentScore需要审核,我们计划创建审核表StudentScoreHistory-; u  a% Q) @! a' y, p, K2 |) N! I1 i
Table StudentScoreHistory (    StudentScoreHistoryID,-- PK    StudentScoreID,   StudentID,   CourseID,   AuditActionCode,   AuditDateTime,   AuditActionUserID)如果修改了StudentScore任何一行,我们都会把旧行移到StudentScoreHistory。
+ i" k# }/ J; o* g在设计讨论中提出的观点之一是StudentHistory表中的StudentID和CourseID设置为FK,保持参考完整性。支持这一点的原因是我们0 n7 }6 i5 g* J$ C
通常总是    删除软(逻辑布尔标志)而不是硬删除,有利于保持引用的完整性,以确保我们在审计表中没有孤立ID。
( q! p. U& i# OTable StudentScoreHistory  StudentScoreHistoryID,-- PK    StudentScoreID,   StudentID ref Student(StudentID),-- FK to Student    CourseID ref Course(CourseID),-- FK to Course    AuditActionCode,   AuditDateTime,   AuditActionUserID)这对我来说似乎有点奇怪。我真的同意了@Jonathan' R5 j. C- S% K
Leffler评论,即审计记录不应阻止删除父亲的数据。相反,如有必要,应通过主表中的外键而不是审计表中的外键进行处理。我想征求你的意见,以确保外键在扩展到审计表时不会失去任何价值。  c# ^/ `9 G0 E5 n/ f
现在我的问题是:    这些外键是否包含在历史记录表中是一个很好的设计?7 F, u: S; j8 N* m+ B. \9 A
我们将感谢任何关键论点的细节(如性能、最佳实践、设计灵活性等)。
2 J0 L4 h2 D$ Q任何寻求特定目的和我们环境的人的利益:
+ E; C% Z' w& M4 Q; y目的:' w! X7 q6 c& Y- n4 R) F. Z4 @
[ol]维护关键数据历史6 P  a, `% Z9 N6 i
允许审查用户活动并支持重建计划
$ m. O2 {1 U: Z1 ^# b& L在一定程度上允许回滚用户活动[/ol]环境:
/ }* @. M8 K: n2 X交易数据库2 g( O- A6 A: j* i# u
并不是每个表都需要审核5 t. f- P2 _7 E) M4 U* g7 \& T
尽量使用软删除,特别是静态/参考数据+ l/ a* l  g$ y7 b
很少有高度事务性的表使用硬删除
                                                                . m3 c: S6 M3 ^0 [* M6 o
    解决方案:
分享到:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则