使用外键作为主键可以吗？

小开

我不会这样做。我将保留 profileID作为表 Profile的主键

外键只是两个表之间的引用约束

可以认为，主键作为从其他表引用它的任何外键的目标是必要的。外键是任何表中一列或多列的集合(不一定是该表的候选键，更不用说主键了) ，它可能包含在其他表的主键列中找到的值。所以我们必须有一个主键来匹配外键。还是我们必须这么做？主键/外键对中的主键的唯一用途是提供一个明确的连接，以维护与保存引用主键的“ foreign”表的参照完整性。这样可以确保外键引用的值始终有效(如果允许，则为 null)。

Http://www.aisintl.com/case/primary_and_foreign_key.html

小开

最佳答案

外键几乎总是“允许重复”，这将使它们不适合作为主键。

相反，找到一个唯一标识表中每条记录的字段，或者添加一个新字段(自动递增整数或 GUID)作为主键。

唯一的例外是具有一对一关系的表，其中链接表的 外国人键和初选键是同一个键。

小开

主键始终需要是唯一的，如果表是一对多关系，则外键需要允许非唯一值。如果表是由一对一关系而不是一对多关系连接的，那么使用外键作为主键是完全可以的。如果您希望同一个用户记录拥有多个相关配置文件记录的可能性，请使用单独的主键，否则请坚持使用您拥有的记录。

小开

这取决于业务和系统。

如果 userId 是唯一的，并且始终是唯一的，则可以使用 userId 作为主键。但是如果你想要扩展你的系统，它会使事情变得困难。我建议您在表用户中添加一个外键，以便与表配置文件建立关系，而不是在表配置文件中添加一个外键。

小开

一般认为一对一的关系是不好的做法。这是因为您只需要在一个表中表示数据，就可以得到相同的结果。

但是，在某些情况下，您可能无法对所引用的表进行这些更改。在这个例子中，使用外键作为主键没有问题。拥有一个由自动递增的唯一主键和外键组成的组合键可能会有所帮助。

我目前正在开发一个系统，用户可以登录并生成一个注册代码来使用一个应用程序。由于某些原因，我不能简单地将所需的列添加到 users 表中。所以我要和代码表一对一地讨论。

小开

是的，在这些表之间存在一对一关系的情况下，外键可以是主键

小开

是的，将主键作为外键是合法的。这是一种罕见的结构，但适用于:

一个1:1的关系。这两个表不能合并在一个表中，因为不同的权限和特权只适用于表级别(到2017年，这样的数据库将是奇数)。
一个1:0. . 1的关系。配置文件可能存在，也可能不存在，这取决于用户类型。
性能是一个问题，设计充当分区: 与用户表相比，配置文件表很少被访问，托管在单独的磁盘上，或者有不同的分片策略。如果下划线存储为柱状，则不合理。

小开

简短的回答: 视情况而定。在这种特殊情况下，可能没问题。然而，专家们几乎每次都会建议不要这么做，包括你的情况。

为什么？

如果键与所涉及的表不相关(起源于另一个表) ，则表中的键很少是唯一的。例如，项目 ID 在 ITEMS 表中可能是唯一的，但在 ORDERS 表中不是，因为同一类型的项目很可能存在于另一个顺序中。同样，订单 ID 在 ORDERS 表中可能是唯一的(可能) ，但是在其他表(如 ORDER _ DETAILS)中不是这样，在 ORDER _ DETAILS 中可能存在具有多行项目的订单，并且为了以特定的顺序查询特定的项目，需要将两个 FK (ORDER _ id 和 item _ id)连接起来作为这个表的 PK。

我不是数据库专家，但如果你可以合理地证明有一个自动生成的值作为你的 PK，我会这样做。如果这不实际，那么两个(或更多) FK 的连接可以作为您的 PK。但是，我想不出任何情况下，一个单一的 FK 值可以证明为 PK。

小开

它并不完全适用于这个问题的情况，但是因为我最终在这个问题上搜索了其他信息，并且通过阅读一些评论，我可以说在一个表中只有一个 FK 并得到唯一值是可能的。你可以使用一个有类的列，这个类只能分配一次，它的工作方式和 ID 差不多，但是如果你想使用一个唯一的分类值来区分每个记录的话，它也可以这样做。