C# 在诸如CreatedBy/ModifiedBy之类的sql审核列中存储UserId而不是Username的优点

我一直想知道为什么在大多数示例/教程中，每个人都将用户名存储在审计数据库列中，例如

CreatedBy

/

ModifiedBy

在我的脑海里，我一直在想，如果我正在构建的系统允许用户更改用户名，只要不使用该用户名，该怎么办

在这种情况下，我不想存储用户的Id吗

---

我真的不希望这是一个基于观点的问题。因此，我所期望的答案是，在审计列中存储用户名是可以的，在审计列中存储用户id是可以的。

这不可能不是一个基于意见的问题。但是，考虑使用USER ID时会发生什么。下一个逻辑结论是为用户表生成一个外键。现在，如果用户有审核行，则不能删除该用户

好吧，没什么大不了的。跳过外键并输入没有外键的UserID。现在，如果删除用户行，审核信息有多有用？特别是如果您有一个身份或唯一标识符作为您的用户ID。该值现在完全没有用处，因为要从中派生任何值，必须连接到用户表

---

现在你知道为什么大多数时候你看到的是用户名而不是用户名了吗？

大多数人在

字段中使用用户名，并由
修改为网络用户id，例如，如果我的用户名是
John fields
的话，那么可能会将其存储为
jfields
如果用户id总是数字的，那么在数字字段上排序比在varchar字段上排序快得多。。它完全基于
意见/部门偏好
没有理由不能在审计表中同时存储
用户ID
和
用户名
；只需确保在任一字段上禁用任何FK约束。@MethodMan我喜欢这种方法，但如果用户可以在系统中更改他们的名字和姓氏，它仍然不是100%可靠的。例如，如果一个女人结婚了。这就是你的人力资源部门和Peoplesoft或ActiveDirectory。在这种情况下，唯一的事情是系统中的
用户ID
，它不应该改变@BlakeRivell你为一家有it部门、主管或首席开发人员的公司工作吗？我想问一下，在您的公司中编写/设计审计试验时，标准是什么case@BlakeRivell-不仅仅是女人，男人和女人在结婚时都可以改变自己的名字，比如在姓氏上连字符。这是一个惊人的答案。我很失望，考虑到我的经验，我自己没能想清楚这一点。因此，您要说的是，实际上没有安全的方法来存储此字段，并且始终使其100%可靠，除非涉及到规则（例如用户永远无法删除）。我假设这就是日志记录的用武之地，这样您就可以随时看到谁通过日志记录做了什么。很抱歉，如果这个问题是基于意见的，但是我认为你的答案对很多人都有帮助。你可以在用户表上实现软删除，这样就完全可靠了。当然，这有它自己的挑战，但可能是在某些情况下的解决方案。现在考虑当另一个同名用户出现时会发生什么。他是否做了所有这些正确或恶意的数据修改？他是否有权访问先前用户创建的所有记录？我想不是。这就是为什么您必须存储所有链接的敏感数据或清除引用已删除行的所有内容。@IvanStarostin这正是我声明这将主要基于观点的原因。对这类事情没有正确或错误的答案。在一个环境中起作用的可能在另一个环境中不起作用。在某些系统中，您所描述的事情可能很关键，而在其他系统中，这并不重要。甚至在某些系统中，这些都是广告帐户，只会被禁用，因此实际上不可能复制。与SQL Server的所有内容一样……这取决于：D