我正在使用一种产品，几乎每张桌子都有这些列。作为开发人员，我们不得不加入到Users表中以获取创建记录的ID，这只是代码中的一个混乱。
我正在设计新产品并再次思考这个问题。它必须是这样的吗？显然，知道谁创建了记录以及何时创建记录是件好事。但是有300多个表引用相同的User表似乎不是很好..
你如何处理这样的事情？我是否应该仅在UI上最需要的主要实体上创建CreatedBy列，而不是处理加入？或者我应该把它放到任何地方？或者可能有另一个“审核”表，我存储所有这些并仅按需查找（不是每次在UI上显示实体）
我只是担心每个UI查询都会触及User表的性能方面。
编辑：这将是SQL Server 2008 R2数据库
答案 0 :(得分：3)
该方法的问题在于您只知道谁创建了行以及谁更改了行 last 。如果最后一个更新行的人正在纠正上一个更新程序的错误怎么办？
如果您有兴趣因合规或问责原因进行全面审核，您应该考虑SQL Server Audit。您可以指定您正在审核哪些表，可以动态更改这些表而不必弄乱您的架构，并且您可以专门针对此数据编写查询，而不是将审计逻辑与您的常规应用程序查询逻辑混合（更不用说扩大每个桌子本身的一排）。这也将允许您审核SELECT查询，其他潜在的解决方案（触发器，CDC，更改跟踪 - 所有这些都是更多工作或不完整以用于真正的审计目的）将不允许您这样做。 / p>
答案 1 :(得分：0)
我知道这是一篇较旧的帖子，但避免在用户表上查找的一种方法是对审核字段进行反规范化。
因此，您不必在CreatedBy字段中输入用户名，而是自己插入用户名。这将允许在没有用户外观的情况下查看表，并且还允许用户表中的任何更改不反映在审计字段中。如删除用户。
我通常将以下内容添加到表的末尾
IsDeleted bit default 0
CreatedBy varchar(20)
CreatedOn datetime2 default getdate()
UpdatedBy varchar(20)
UpdatedOn datetime2 default getdate()