c# - EF 或 SQL 是审计数据更改的更好选择吗？

Question

要求看起来很简单:当数据更改时，审核更改。

这里有一些重要的方程式:

1. 我的应用程序中的数据跨越多个表(一些交叉引用表)。
2. 我的 DTO 很深，有条件地填充导航属性。
3. 加载时，我复制原始 DTO 及其“原始值”。
4. 请求保存时，原始 DTO 包含更改。
5. 理想情况下，外键读起来像是有用的文本，而不是 ID 号。

与 TFS 的酷历史功能不同，我的功能似乎更复杂，因为有许多相关表和条件子实体。

我看到三种可能性(到目前为止):

1. 我可以使用 C# 来反射(reflect)对象并创建之前/之后的记录。
2. 我可以在 SQL 2008R2 中使用触发器来捕获更改并合并之前/之后的记录。
3. 我可以存储原始的前后对象并让 SQL 2008R2 解析它们。

请注意:目前，在我看来，SQL 2008R2 的 CDC 是一个过于沉重的选择。我真的在寻找我可以构建的东西，但我承认我现在对任何事情都持开放态度。

我的问题

在开始构建之前:其他人如何处理复杂的 EF DTO 的审计？

是否有可用的低技术解决方案？

提前谢谢你。

StackOverflow 上已有相关但不完全相关的问题:Implementing Audit Log / Change History with MVC & Entity Framework和 Create Data Audit in SQL Server和 https://stackoverflow.com/questions/5773419/how-to-audit-many-to-many-relationship-in-entity-framework和 Maintaining audit log for entities split across multiple tables和 Linq to SQL Audit Trail / Audit Log: should I use triggers or doddleaudit?不要提供答案。

Answer 1

如果审计是一个真正的要求，我会选择触发解决方案......因为其他方法有几个“缺点”:

• 对通过您的申请以外的其他方式发生的任何变化“视而不见”
• 如果您更改了一些代码而忘记了添加审计代码，审计跟踪就会出现“盲点”

基于触发器的解决方案可以得到保护，因此只有特殊用户甚至可以看到审核数据...

我通常使用 Oracle，但根据我在这种情况下的经验:仅允许应用程序通过 View 进行 SELECT 权限，任何插入/删除/更新都应通过存储过程完成，审计跟踪应通过触发器完成...