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

Joe*_*ner 8 mysql

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

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

一种可能的布局,我会说是常见的方法,因为我在大多数软件中观察到,是使用这样的自动增量 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))
Run Code Online (Sandbox Code Playgroud)

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

另一种方法是:

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))
Run Code Online (Sandbox Code Playgroud)

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

对我来说,这有以下优点:

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

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

但也有缺点:

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

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

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

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

  • 有没有最佳实践?

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

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

小智 3

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

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

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