【发布时间】：2021-03-19 02:19:48
【问题描述】：
如果您总是知道从某个 API 返回的值（在这种情况下为字符串）将是唯一的，那么可以使用该值作为主键来唯一地定义记录吗？
真的有必要添加一个额外的“id”列，它只是一个自动递增的值吗？
【问题讨论】：
标签： mysql sql database postgresql
【发布时间】：2021-03-19 02:19:48
【问题描述】：
自然主键作为主键是完全可行和合理的。但是，有一些事情需要考虑：
- 主键的主要用途之一是外键关系。整数主键非常小并且长度相同。字符串不适合索引，因为它们（通常）长度不同并且（通常）比整数长。
- 您确定主键的定义不会随时间改变吗？
- 在一堆表（具有外键引用的表）中显示外部键是否安全（从隐私/安全角度）。
我会说合成外键（即作为数字创建的人造外键）可能有缺点。如果您对创建的每个数据库都执行此操作，那么您在整个数据库中都有不兼容的键。因此，“产品 ID”之类的内容最终取决于定义它的系统——这可能会导致不必要的混淆。
【讨论】：
-
假设我使用的那些密钥是否来自 API，例如：API 可能会发回订单和约会。现在，约会和订单在此场景中具有 1 对 1 的关系。使用 API 的 ID 作为主键/外键约束会更好，还是应该使用我自己生成的 ID？
-
我完全同意。如果数据库中有很多记录，那么肯定会产生影响的是数据库的增长。表和索引的大小是应该考虑的事情。一种经常使用的模式：使用通用 PK 并将“自然” pk 作为唯一列添加到表中，这样您就可以在性能和大小损失很小的情况下获得通用键的优点。
-
@stuy：基本上“应该”使用你得到的密钥是可以的，但另一方面你无法控制 API，如果有一个错误你可以得到一个 id 两次' t 做任何事情.. 如果你有一个通用的 id，你仍然可以处理它
除了性能问题之外，PK 还必须服务于业务逻辑。 PK 并不总是必须只是一个自动序列号。自动序列号对于快速用户交互（例如查询和更新请求）以及在 ETL 案例中仍然有用。考虑如果 API 发生变化并且不会总是返回唯一值会发生什么。此外，查看您的数据行并确定可以使记录在商业意义上独一无二的一列或多列。您可能会获得或更多“候选主键”。考虑使用最短的那些而不是 API 密钥，而不是自动序列。简而言之，我建议您不要依赖您无法控制的数据，除非某个来源的“合同”表明它始终是唯一的。
【讨论】：