将外键用作主键可以吗？

我有两个表：

• 用户（用户名，密码）
• 个人资料（个人资料ID，性别，出生日期等）

当前，我正在使用这种方法：每个Profile记录都有一个名为“ userId”的字段作为外键，该字段链接到User表。用户注册后，将自动创建其个人资料记录。

我很困惑与我的朋友建议：有“用户id”字段作为外国和主键和删除“简档”字段。哪种方法更好？

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

而是，找到一个唯一标识表中每个记录的字段，或者添加一个新字段（自动递增的整数或GUID）作为主键。

唯一的例外是具有一对一关系的表，其中链接表的外键和主键是相同的。

如果表是一对多关系，则主键始终需要唯一，外键必须允许非唯一值。如果表是通过一对一关系而不是一对多关系连接的，则将外键用作主键是完全可以的。如果您希望同一个用户记录具有多个相关的个人档案记录，请使用单独的主键，否则请坚持使用您拥有的主键。

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

• 1：1关系。这两个表不能合并为一个表，因为不同的权限和特权仅适用于表级别（从2017年开始，这样的数据库很奇怪）。

• 1：0..1关系。配置文件可能存在或不存在，具体取决于用户类型。

• 性能是一个问题，设计是一个分区：与用户表相比，概要文件表很少被访问，位于单独的磁盘上或具有不同的分片策略。如果下划线存储是柱状的，则没有任何意义。

建立一对一关系通常被认为是不好的做法。这是因为您可以只将数据表示在一个表中并获得相同的结果。

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

我目前正在使用一个系统，用户可以在该系统上登录并生成用于应用程序的注册码。由于某些原因，我将不进行介绍，因此我无法简单地将所需的列添加到users表。所以我要沿着代码表进行一对一的选择。

是的，在这些表之间一对一的关系中，外键可以是主键

我不会那样做。我将保留profileID表的主键Profile

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

可能有人争辩说，主键是作为从其他表引用它的任何外键的目标所必需的。外键是任何表中一个或多个列的集合（不一定是该表的候选键，更不用说主键了），它可以保存某些表的主键列中的值。其他表。所以我们必须有一个主键来匹配外键。还是必须？主键/外键对中主键的唯一目的是提供明确的连接-相对于保存引用的主键的“外”表保持引用完整性。这样可以确保外键引用的值将始终有效（如果允许，则为null）。

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

这取决于业务和系统。

如果您的userId是唯一的并且将一直都是唯一的，则可以将userId用作主键。但是，如果您想扩展您的系统，那将使事情变得困难。我建议您在表用户中添加外键以与表概要文件建立关系，而不是在表概要文件中添加外键。

简短答案：取决于...。在这种情况下，可能会很好。但是，专家几乎每次都会建议这样做。包括你的案子

为什么？

当键在所讨论的表中是外来键（起源于另一个表）时，表中的键很少是唯一的。例如，一个项目ID在ITEMS表中可能是唯一的，但在ORDERS表中可能不是唯一的，因为相同类型的项目很可能会以另一顺序存在。同样，订单ID在ORDERS表中可能是唯一的（可能），但在ORDER_DETAILS之类的其他表中可能不是唯一的，在该表中可以存在具有多个订单项的订单，并且要查询特定订单中的特定项目，您需要将两个FK（order_id和item_id）作为此表的PK。

我不是数据库专家，但是如果您可以合理地证明有一个自动生成的值作为PK，我会这样做。如果这不切实际，则两个（或更多）FK的串联可以用作您的PK。但是，我无法想到可以将单个FK值证明为PK的任何情况。