复合主键

Question

我正在设计一个数据库，该数据库将用于存储来自许多不同来源的数据。我存储的实例由原始源分配唯一的I。我存储的每个实例都应该包含有关其来源的信息，以及与该来源相关联的ID。

作为示例，请考虑说明该问题的下表：

----------------------------------------------------------------
| source_id | id_on_source | data                              |
----------------------------------------------------------------
| 1         | 17600        | ...                               |
| 1         | 17601        | ...                               |
| 2         | 1            | ...                               |
| 3         | 1            | ...                               |
----------------------------------------------------------------

请注意，虽然每个源的id_on_source都是唯一的，但对于不同的源，也可以找到相同的id_on_source。

我对关系数据库有很好的理解，但我还远不是一个专家，甚至不是一个有经验的用户。我在这种设计中面临的问题是我应该使用什么作为主键。数据似乎规定了(source_id, id_on_source)的组合主键的使用。然而，在用谷歌搜索了一下之后，我发现了一些关于复合主键的利弊的激烈辩论，这让我有点困惑。

该表将与其他表具有一对多关系，因此将在其他表的外键中引用。

我并不局限于某个特定的RDBMS，我不确定这是否与争论有关，但假设我更喜欢使用SQLite和MySQL。

在这种情况下使用复合外键的优缺点是什么？你要选哪个？

Answer 1

我个人发现复合主键是痛苦的。对于要连接到"sources“表的每个表，都需要添加source_id和id_on_source字段。

我将在sources表上创建一个标准的自动递增主键，并在source_id和id_on_source列上添加一个惟一索引。

这样就可以将sources表的id作为外键添加到其他表中。

一般来说，我还发现在许多框架和工具产品中对组合主键的支持充其量是“零散的”，在其他框架和工具产品中是不存在的

Answer 2

组合键很难管理，连接起来也很慢。因为您正在构建一个汇总表，所以使用一个代理键(例如，一个自动增量/标识列)。把你的自然键列留在那里。

这也有很多其他的好处。首先，如果你和一家公司合并，他们有一个相同的源，但是重用了键，如果你不使用代理键，你就会遇到麻烦。

这是数据仓库中被广泛认可的最佳实践(这是一项比您正在做的工作大得多的工作，但仍然是相关的)，而且有充分的理由。代理提供数据完整性和快速联接。使用自然键可能很快就会被烧焦，所以不要将它们作为标识符，只在导入过程中使用它们。

Answer 3

您有一个业务需求，即这两个属性的组合是唯一的。因此，您应该在这两个属性上有一个UNIQUE约束。无论您是否将UNIQUE约束称为“主”，实际上只是一种偏好，除了文档之外，它没有太大的影响。

唯一的问题是，您是否随后添加了一个额外的列并将其标记为UNIQUE。我认为这样做的唯一原因是性能，这是一个合法的原因。

就我个人而言，我不喜欢将每个数据库都变成一个本质上是图形的方法，在这种方法中，生成的列本质上是指针，而您只是从一个数据库遍历到下一个。我认为这抛弃了关系系统的所有伟大之处。如果你退一步想一想，你会发现你引入的是一堆对你的业务毫无意义的专栏。你可能会对我的related blog post感兴趣。