我读过几本不同的书籍和资源:
- 外键必须指向候选键(或主键)
- 外键几乎总是指向主键
来源的作者总是说一些类似的话，“虽然外键可以指向他们似乎指向的候选键(而不是主键)”。
您可以选择候选键而不是主键的示例有哪些？
最佳答案
主键 (PK) 在关系理论中没有作用。 (例如完整性或规范化。)PK 只是您决定称为“主要”的一些候选 key (CK)。外键 (FK) 引用 CK。 CK 是一个不包含更小 super 键(唯一列集)的 super 键。当一个表有多个 CK 而另一个表引用一个恰好不是 PK 的表时，您仍然应该声明一个 FK。 DBMS 可以将 PK 声明用于其他目的。
在 SQL 中，UNIQUE NOT NULL 声明类似于 super 键。 SQL PK 声明强制执行 UNIQUE NOT NULL 约束，因此通常它也声明 super 键的模拟，而不是 CK——可以在其中声明更小的 UNIQUE NOT NULL 或 PK( super 键)，但 CK 不能包含更小的 super 键。并且 SQL FK 声明声明我们可以称之为外部 super 键的类似物:引用列列表引用 PK 或 UNIQUE(不一定非 NULL)声明中的列列表。
Does an empty SQL table have a superkey? Does every SQL table?
关系 FK 约束表示源表某些列下的子行必须显示为引用表的 CK 子行。 SQL FK 约束表示源表某些列下的无 NULL 子行必须显示为引用表的 UNIQUE(可能是 PK)子行。 (详细信息取决于 SQL MATCH 模式；通常只支持默认模式。)当情况如此且不是先前 FK 声明的结果时，声明一个 FK。
例如:化学元素表合理地具有三个 CK:名称、符号和原子序数。只有一个可以PK。然而，只要任何列出现在另一个表中，就应该为它们声明 FK。如果不止一个同时出现指的是同一个元素，它们应该形成一个复合 FK。 (并且每个的 FK 声明都是多余的。)
关于sql - 什么时候应该使用指向候选键而不是主键的外键的例子？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37097509/