Question

这是我在互联网上找到的用户管理数据库的设置（用伪代码编写）。虽然看起来很好，但我不明白为什么users表有id以及唯一的非空username列。我不能只使用用户名作为id（主键）吗？

users
(
  id integer primary key,
  username varchar(100) not null unique key,
  pwd varchar(50) not null
);

user_roles
(
  user_id integer not null,
  role_id integer not null,
  unique key (user_id, role_id),
  index(user_id)
);

roles
(
  id integer primary key,
  role varchar(100) not null unique key
);

Answer 1

我总是回到Kimberly L. Tripp的recommendations for a clustering key（默认情况下，它是SQL Server中的主键）。

她的标准是聚类键应该是：

唯一（ID和名称之间的关系）
缩小（ID为+1）
静态（可能 +1代表ID，具体取决于是否允许更改名称）
不断增加（可能 +1的ID，取决于它的实现方式，这里使用IDENTITY列将是理想的情况）

Answer 2

是的，您可以使用用户名。问题是可能不稳定的主键很痛苦，因为您需要将更改级联到所有FK。

在连接中使用整数往往表现更好

你应该注意到，关键波动的原因有点主观

同样正如JNK所提到的，当聚集索引（通常也是PK）是增量int时，还有一个优化。参见Kimberly L. Tripp的文章The Clustered Index Debate Continues

Answer 3

您可以（使用user_id作为主键）。

我看到的唯一障碍是：如果需要更改user_id（ Stephanie Smith 与某个名为 Johnson 的人结婚并需要她user_id已更改），则数据库维护较少。

在我工作的地方，有人设置我们的数据库，以便在几年前使用user_id作为主键。现在改变这将是一场噩梦！

另外，int搜索速度更快，可以自动生成。

Answer 4

这会使加入效率低下：int s比varchar(100)小得多，因此索引会更小，更快。通常，主键将是表的聚集索引。

Answer 5

我认为你可以使用用户名作为主键。也许这个例子使用id列来获得更好的性能。我想，搜索Int列比使用文本更快。同样在user_role表中有一个foreign_key user_id。没有意义，在这种情况下使用字符串（100）作为foreign_key。

Answer 6

在高级别，你在这里谈论自然与代理键。有一些权衡，我认为已经提到过，但如果你想要额外的阅读，我会说这个链接总结得很好

"Natural and Surrogate Keys"

Answer 7

基本上，ID是存储在数据库中的自动增量值，用于在DB脚本中进行引用，但用户名也是唯一列。最大的好处是您的用户无需记住已分配给系统登录帐户的任何数字编号，而是可以选择自己唯一的用户名并轻松进行交互。

使用用户名列而不是ID？

7 个答案: