在关系数据库中选择主键的最佳实践，最聪明的解决方案是什么？
Best practice to choose primary keys in a relational DB, what is the smartest solution?
我正在设计一个关系数据库，我对处理主键的最佳实践有以下疑问
我有一些 tables，其中拥有主键的唯一方法是设置一个名为 id.
的 BIGINT autoincrement 列
其他 table 包含可用作主键的单义数据（例如，我有一个 Country table 包含一个单义 country_code 列）。
我的问题是：这种情况下的最佳做法是什么？我仍然使用名为 id 的 BIGINT autoincrement 列，或者在这种情况下最好使用单义数据作为主键？
即使 table 有一个很好的自然键，通常最好分配一个代理键（通常是数字自增列）。
首先，正如 jarlh 指出的那样，即使是国家/地区也可以并且确实会不时更改其名称，您可以使用 CountryID 值轻松处理。
此外，很多时候自然键是由字符数据组成的。 SQL 处理数字比处理字符更快，因此使用数字 ID 值可以提高性能。
这是目前数据仓库的标准做法，因此开发人员习惯于看到那些 SK 列。
最佳做法？大概。标准做法？确实。使用自动增量。
计算机科学中有一个完整的主题，称为 数据库规范化， 他们在其中讨论 "first, second, and third normal forms."
其中一个主要问题是数据库键本身不应携带信息。他们应该 "unambiguously identify the row" 仅此而已。因此，自动递增整数是用作主键的好东西。然后，在 country_code.
上放置一个索引......也许是 UNIQUE 索引......
在其他应用程序中，我使用了诸如 uuid's ... 保证唯一的标识符字符串 ... 作为主键。数据库自动生成 uuid 值。现在，我可以毫无歧义地从一个数据库传输 到另一个数据库。 （我还在使用自动增量键的数据库中使用了自动生成的 uuid 字段 。）
因此，您确实有几个不错的选择，但在每种情况下，主键 仅 标识行，而不是 "part of the data."
我正在设计一个关系数据库，我对处理主键的最佳实践有以下疑问
我有一些 tables，其中拥有主键的唯一方法是设置一个名为 id.
BIGINT autoincrement 列
其他 table 包含可用作主键的单义数据（例如，我有一个 Country table 包含一个单义 country_code 列）。
我的问题是：这种情况下的最佳做法是什么？我仍然使用名为 id 的 BIGINT autoincrement 列，或者在这种情况下最好使用单义数据作为主键？
即使 table 有一个很好的自然键，通常最好分配一个代理键（通常是数字自增列）。
首先，正如 jarlh 指出的那样，即使是国家/地区也可以并且确实会不时更改其名称，您可以使用 CountryID 值轻松处理。
此外，很多时候自然键是由字符数据组成的。 SQL 处理数字比处理字符更快，因此使用数字 ID 值可以提高性能。
这是目前数据仓库的标准做法，因此开发人员习惯于看到那些 SK 列。
最佳做法？大概。标准做法？确实。使用自动增量。
计算机科学中有一个完整的主题，称为 数据库规范化， 他们在其中讨论 "first, second, and third normal forms."
其中一个主要问题是数据库键本身不应携带信息。他们应该 "unambiguously identify the row" 仅此而已。因此，自动递增整数是用作主键的好东西。然后，在 country_code.
UNIQUE 索引......
在其他应用程序中，我使用了诸如 uuid's ... 保证唯一的标识符字符串 ... 作为主键。数据库自动生成 uuid 值。现在，我可以毫无歧义地从一个数据库传输 到另一个数据库。 （我还在使用自动增量键的数据库中使用了自动生成的 uuid 字段 。）
因此，您确实有几个不错的选择，但在每种情况下，主键 仅 标识行，而不是 "part of the data."