对于外键设计，增加 id 与全文键的权衡是什么？

Question

在许多关系数据库设计中，有些字段会在其他表中引用。

例如，考虑具有唯一用户名的用户表和存储地址数据的第二个表。

一种可能的布局，我会说是常见的方法，因为我在大多数软件中观察到，是使用这样的自动增量 id：

Table users
===========
userId int primary auto_increment
userName varchar unique

Table adressdata
==========
userId int references users.userId
adress_type varchar // for example country
address_value varchar // for example US
(you probably also want to put a unique key on (userId,adress_type))

这就是我过去常常这样做的方式，也是我在大多数情况下看到的方式。

另一种方法是：

Table users
===========
userName varchar primary

Table adressdata
==========
userName varchar references users.userName
adress_type varchar // for example country
address_value varchar // for example US
(you probably also want to put a unique key on (userName,adress_type))

这里我们也将完整的用户名存储在地址数据表中。

对我来说，这有以下优点：

• 您可以立即从表中选择用户名，而无需将其加入另一个表。在此示例中，这从应用程序的角度来看可能不太相关，但这只是一个示例。

• 在 master-master 复制环境中扩展数据库可能更容易，因为不存在 auto_increment 冲突。

但也有缺点：

• 第二个表中字段的索引和数据（但更相关的可能是索引）的空间要求更高。
• 用户名的更改需要传播到所有表，这比仅在一个表中更改它并保持 id 不变更消耗资源。

在我看来，使用文本字段更容易并且不使用增量 id，并且权衡是最小的，并且在大多数应用程序中不相关。

当然，某些对象根据其性质用递增的数字标识（例如，论坛帖子应该接收递增的 id，因为可能没有其他唯一字段，如标题等）。

但是在我开始以完全不同的方式设计我的数据库布局之前，我想知道是否有我没有想到的事情。

• 有没有最佳实践？

• 是否有我没有想到的利弊，以及可能会在以后出现的影响？

• 您个人如何设计关于上述几点的数据库，为什么？

Answer 1

我建议使用 id 而不是用户名，因为如果您开始使用用户名作为多个表中的连接列，您必须记住更新所有表。

表的外键users成为表的主键，addressdata并且主键必须保持稳定。最好不要更改主键字段。主键在创建记录时必须存在，并且在记录的整个生命周期内必须保持不变。

如果您想获得更多见解，伟大的主键辩论是一篇很棒的文章。