为什么这种外键是可能的？

Question

为什么 SQL 标准接受这一点？ 有哪些好处？

如果有这些表：

create table prova_a (a number, b number);
alter table prova_a add primary key (a,b);
create table prova_b (a number, b number);
alter table prova_b add foreign key (a,b) references prova_a(a,b) ;
insert into prova_a  values (1,2);

您可以插入这个而不会出现错误：

insert into prova_b  values (123,null);
insert into prova_b  values (null,123);

Note1：这来自于答案。

注意2：这是可以避免的，在两列上设置不为空。

备注：我不是在问避免，我感兴趣的是有哪些好处。

参考资料：

• Oracle 文档：关系模型允许外键的值与引用的主键或唯一键值匹配，或者为空。 如果复合外键的任何列为空，则该键的非空部分不必与父键的任何相应部分匹配。

• SQL Server 文档：FOREIGN KEY 约束可以包含空值； 但是，如果复合 FOREIGN KEY 约束的任何列包含空值，则将跳过对组成 FOREIGN KEY 约束的所有值的验证。

Answer 1

我知道一些 DBMS 在涉及具有外键约束的外键时根本不强制执行引用完整性。 我想到了 SQLite。 此处对此进行了讨论。

其他 DBMS 有所不同，我知道如果您尝试类似的操作，MS SQL Server 会抱怨。

SQLite 有它的用途，但它并不适合在高并发情况下使用。 如果您在不同的 DBMS 中看到此行为，请检查他们的文档，看看他们是否做了类似的事情。 然而，大多数人应该加强诚信。

Answer 2

至少让你的开发工作使用一个相当标准的 RDBMS，即使你正在使用 SQLite（这是一个优秀的数据库 - 它在你的 Ipod touch 中运行！）之类的东西来处理你的生产系统，它会清除所有这些错误 - 就像 Lint 真的一样。 如果您使用可以免费下载的 SQL Server Express 运行代码，您将收到大量错误，例如...

Msg 8111, Level 16, State 1, Line 2
Cannot define PRIMARY KEY constraint on nullable column in table 'prova_a'.
Msg 1750, Level 16, State 0, Line 2
Could not create constraint. See previous errors.

Answer 3

Oracle 和 SQL Server 都允许 NULL 外键，并且很容易理解为什么这是必要的。
例如，考虑一棵树，其中每一行都有一个引用同一个表的主键的父键。 树中必须有一个没有父节点的根节点，并且父节点键将为空。
一个更具体的例子：想想员工和经理。 公司里有些人，如果只有CEO，就不会有经理。 如果无法将员工表上的经理 ID 设置为 NULL，则必须创建一个“无经理”员工 - 这是错误的，因为它没有现实生活中的对应关系。

现在我们知道了这一点，复合键的行为原因就很明显了。 从逻辑上讲，如果组合的一部分为 NULL，则整个键为 NULL。 如果其中一个字符串为 NULL，则字符串连接将返回 NULL。 不可能存在匹配，并且在这些情况下不强制执行约束。

Answer 4

SQL 标准不接受这一点； 您发现了一个不强制执行引用完整性的 DBMS。 如果您够聪明，请立即卸载它。 至少不要将其用于生产目的。

早期的 SQL 标准 (SQL86) 没有引用完整性，而 SQL89 级别 2 修复了这个问题。

Answer 5

尝试添加此声明：

alter table prova_b add Primary key (a,b);

这将禁止 prova_b 中的 NULL。 它还将禁止重复条目。 在Oracle和SQL Server中，它也会创建索引。 该索引将加快查找和连接速度，但代价是稍微减慢插入速度。

这是你想做的吗？

至于为什么标准 SQL 会让你做一些你认为愚蠢的事情，这是一个哲学问题。 大多数工具都允许一些愚蠢的选择。 试图禁止所有愚蠢选择的工具通常最终会无意中禁止一些真正明智的选择。