的修改/创建信息

使用审核表我需要保持我的大多数实体的修改/创建信息

CreatedByUserId
ModifiedByUserId
CreatedDateTime
ModifiedDateTime

的轨道。相当标准。

您认为最好将这些列添加到每个表......或者只需要在要审计的表上有一个CreatedAuditEntryId和ModifiedAuditEntryId FK，它指向现有的用于跟踪所有更改的单独审计表。

AuditEntry样子：

编号
用户ID
日期时间

有不得不做的明显的性能影响，2连接，以获得创建和修改信息...但好处是我没有在两个不同的地方保持状态，这就像我设计书中的第一基本规则。

UPDATE：

只是要清楚，AuditEntry表包含了每一个修改每个表，不管。这里的问题是，是否利用了表通过FKS创建和修改信息...或只加上面我想要的信息，每个表四列，从而避免了连接。

来源

2011-06-29 Jeff

我的选择将是一个FK关系的独立的审核表，否则你只能看到最后一个条目，这是没有太大的审计...

你在使用更新这些条目？如果用户ID可以从SQL用户隐含它可以全部在触发器中完成。

我看在谁，什么时候和到什么类型的表MVC相似，要实现一个过滤器来记录整个系统的控制器操作的东西。

编辑：鉴于更新的问题，其中很明显的是，审计表无论如何都会被现有的，我不得不选择链接到审计表。拥有不一致审计数据的想法太可怕了！除非应用程序完全被关系设计瘫痪，否则将其保持正常化！

来源

2011-06-29 15:59:49 Andiih

查看有关审计跟踪的更新问题。完整的审计信息将存在，无论...我只是想知道如果连接确实没问题。不幸的是，用户ID不能隐含在SQL中，因此我在保存更改时在EF中处理它。 – Jeff

“更好”取决于你的需求是什么。

如果您所需要的只是最后修改事件，那么将审计列添加到表中会更好（资源方面）。一次更新只需要触摸那一行。

如果在另一方面，你需要为每个人触摸历史次审计记录，那么你有没有选择，只能有一个单独的审计表。

来源

2011-06-29 15:56:54 mjl

见关于审计线索更新的问题。谢谢。 – Jeff

啊，所以它更多的是一个性能问题：“我是否使用现有的表，并且（可能是代价高昂的）连接，或者是否保留了使用原始数据去归一化信息的副本”。在这种情况下 - 除非遇到性能问题 - 请加入并让数据库担心让事情变得更快。如果您总是希望审核数据出现，我甚至会为此创建一个视图。某些数据库可以更快地制作复杂的视图（例如Oracle具有“物化视图”）。 – mjl

的修改/创建信息

回答

相关问题