如何评估复合键？答案

【问题标题】：How are composite keys evaluated?如何评估复合键？
【发布时间】：2014-02-19 19:12:13
【问题描述】：

是否保证复合键是唯一的，只要它所包含的列的各个值是唯一的（如在单独评估列值中），或者它是结果值（如在列值的串联中) 构成密钥并且必须是唯一的？

例如，以下两行是否会产生相同的键，或者它们都被认为是唯一的并因此被允许：

PRIMARY KEY (user_id, friend_id)

|-----------|-------------|
|  user_id  |  friend_id  |
|-----------|-------------|
|    10     |     283     |
|   1028    |      3      |
|-----------|-------------|

现在，我显然不是数据库专家，这实际上是我第一次考虑使用复合键（以前从来没有理由），所以它可能是“每个人”都知道的东西，或者真的很容易在文档中找到，但我一直无法找到答案。

您希望上面的示例能够正常工作（从逻辑上讲，为什么不应该呢？单独的值肯定是唯一的），但我真的想在继续我的项目之前确定一下。

【问题讨论】：

我不确定，但我认为很明显，如果复合 PK 的列的连接是唯一的，你就不能说它是唯一的 :-) 因为这不是复合 PK 的概念。现在，您可能会争辩说，某些 INDEX（使查询更快）可以使用复合 PK 列的连接来计算一些哈希（在这种情况下，当然，即使这个哈希也不会是唯一的，尽管好的哈希函数试图尽可能传播其值以保持搜索速度更快）。
现在，如果您想使用 INDEXES 加速您的复合 PK 检查，那么您关于 PostgreSQL 复合 PK 评估内部的问题可能适合这里 :-) IMO

标签： postgresql composite-key

【解决方案1】：

PRIMARY KEY 约束由相关列上的UNIQUE 索引加上所有相关列上的NOT NULL 约束来实现。

“唯一”表示所有列的组合是唯一的。您担心的是两个值('10' || '283') = ('1028' || '3') 的文本表示的串联，但这根本不是复合类型的操作方式。所有字段都被单独考虑，并作为已定义数据类型的值，而不是文本表示。

NULL 值永远不会被视为相等，但 pk 列中不允许使用这些值。

列的顺序与性能有关。随附的复合索引优先使用前导列。此密切相关的答案中的更多详细信息：
PostgreSQL composite primary key

【讨论】：

太棒了。谢谢！这就是我的想法并希望它会起作用，但我之前无法找到答案，所以只能确定。也感谢您的链接。收拾东西了。

【解决方案2】：

每个唯一约束（包括主键约束）都要求关系中的每一行都对约束中指定的属性的投影具有函数依赖关系。

这意味着，在你的例子中，

user_id | friend_id
======= | =========
1       | 1
1       | 2
2       | 1
4       | 5

都是允许的；因为<user_id, friend_id> 中没有对多次出现。鉴于上述情况，您不能再有另一个<1, 1>，因为它会与第一行冲突。

【讨论】：