FK / PK 和 FK 空问题

Question

我正在为我的用户内容网站设计一些表格，但我对这种情况的 FK 概念迷失了。这两种情况有什么不同：

情况 A：
好友表
用户 ID (FK)
friend_id(FK)

案例 B：
好友表
ID（主键）
用户 ID (FK)
friend_id(FK)

我想要理解的是一张表有 2 个 FK，而 1 个表有 2 个 FKS + 1 个 PK。我见过的大多数朋友的模式都有案例 A，只有 2 个 FK，没有 PK。但我看到的大多数其他表都有 PK 的情况 B。那么这两个表有什么区别/优点/缺点以及使用哪一个呢？

---

我遇到的第二个问题是，如果我在表 A 中有一个 PK 并将其用作表 B 中的 FK，那么它在表 B 中是否必须为 NOT NULL，或者即使在表 A 中作为 PK 必须为 NULL，也可以为 NULL不为空？一个例子是绘制城市和州的地图。状态表中的状态必须为 NOT NULL。在城市表中，我将所有值存储为 NOT NULL DEFAULT 0，因为城市没有国家（世界城市），但我不想在数据库中存储 NULL，所以我为所有空值写入 0 只是为了保持单元格被占用。

Answer 1

在情况 A 中，虽然 user_id 和friend_id 是外键，但它们很可能都是复合主键。在情况 B 中，有一个单独的 PK (id) 来标识每个独特的友谊。他们实际上都做同样的事情，但根据我的观点，第二种情况中的id是多余的，因为 PK(user_id,friend_id) 可以一起行动成为一个复合主键，它将唯一地标识每个友谊。我建议你读一本关于标准化的好书:)

Answer 2

根据给出的信息，A和B的区别在于B多了一个列和键约束。哪种设计有意义实际上取决于需求以及数据对您意味着什么。

A 中的主键可能实际上是复合键：（user_id，friend_id）。在这种情况下，两种选择之间的区别在于 A 不允许用户和朋友的重复组合，而 B 则允许这些重复。这是一个显着的差异。

最好避免可为空的外键。如果您有一个并不总是适用的属性，那么您可以随时重新设计表，这样就不需要有可为空的列。将州放入另一个表中，如果该城市没有州，则无需填充该表。

Answer 3

推荐情况A。

当您需要将长复合键迁移到另一个表时，通常会使用情况 B。例如，假设我们需要在表 T1 和 T2 之间创建多对多关系 (T3)。

Case A (natural keys):
table T1(pk1, pk2, pk3, pk4, someValue)
table T2(pka, pkb, pkc, pkd, otherValue)
table T3(pk1, pk2, pk3, pk4, pka, pkb, pkc, pkd, create_date)

需要三个唯一索引（每个表一个）。直接查询T3很方便。

Case B (surrogate keys):
table T1(t1_id, pk1, pk2, pk3, pk4, someValue)
table T2(t2_id, pka, pkb, pkc, pkd, otherValue)
table T3(t1_id, t2_id, create_date)

需要五个唯一索引。与情况 A 中的三个相同，每个代理键加一个。
T3 现在变得小得多，但代价是不再能够在不连接回 T1 或 T2 的情况下查询 M:M 关系。对于任何典型的应用程序来说，这可能是也可能不是一个大问题。

我认为这已经概括了一切。