我的几乎所有表格中都有字段,例如createdBy
or updatedBy
。我认为这仅供参考。
你认为我应该在那里输入用户名还是userID
. 因为如果我需要直接查看数据库,那么这可以提供更好的理解,否则这是一种不好的做法。
我的几乎所有表格中都有字段,例如createdBy
or updatedBy
。我认为这仅供参考。
你认为我应该在那里输入用户名还是userID
. 因为如果我需要直接查看数据库,那么这可以提供更好的理解,否则这是一种不好的做法。
始终使用外键来存储引用记录,在您的情况下是用户 ID。
关于如何存储的方法,这取决于您的需要。
a) 如果您想知道谁最后更新了记录。那么你应该
userID
在表中创建一个列。
存储外键而不是其他记录总是好的,因为这样您可以关联和获取用户的所有记录。但是这种方法会有一个限制,因为您只能存储一个用户 ID,您只能知道谁最后更新了它。
b) 如果您想存储所有记录,要知道哪个用户更新了记录以及何时更新,那么您应该将其存储在一对多关系表中。例如
user_log with columns user_id, update_datetime
也许还有一个消息栏,告诉用户做了什么。
用户身份。因为它们比用户名更小更快。
假设您的用户想要更改用户名,那么您将不需要更新所有表格,这是非常有效的
始终使用 ID 来保持规范化的关系数据结构。这将提供更好的性能和更大的可扩展性。如果您可以包含约束,它将使它更清洁。
这并不总是坏事。捍卫您的应用需求。标准化可以很好地消除冗余。而如果速度是您可以保持原样的因素。因为加入需要时间。插入数据也意味着插入两个表。
从来没有少,总是+1标准化,书上:)
使用以后无法更改的东西。通常这对 user_id 是正确的。
在特殊情况下,您可能还需要存储姓名(以便能够显示当时用户的姓名,在她结婚之前,或者已经被删除的用户的姓名)。但通常,您再次查询数据库以获取(当前)名称(也可以轻松缓存)。
对于用户名,代理键往往是更好的选择。因此,在您的情况下,FK(createdBy
和updatedBy
)将引用代理键(userID
)而不是自然键(用户名)。
但是,这并不意味着 surrogate总是比自然键更好:考虑这个标准列表。