如果我将识别关系从数据库设计的这一部分更改为非识别关系，这意味着什么？

Question

我对此数据库设计有疑问。我有点不确定数据库中识别和非识别关系之间的区别，这让我陷入了一些困惑。

我有这样的数据库设计：（有点像电影租赁店。“朋友”是借电影的人。“工作室”是合作制作电影的制作工作室。）

我有点理解它是如何工作的。但是，我想知道如果我在贷款表中创建一个 loan_id，并使用 movie_id 和 friend_id 作为普通外键会怎样？

我的一些问题是： 后一种方法的优点或缺点是什么？ 初始模型或以后模型更好的情况？ 初始模型是否允许朋友多次借用电影？

任何详尽的解释将不胜感激。

Answer 1

拥有所有多对多表（表协作、贷款、角色）的方式称为复合主键：其中两个（或更多）列形成一个唯一值。

当您有一个复合 pk 时，许多数据库设计人员更喜欢创建一个代理主键（例如您建议的 loan_id）。我就是其中之一。这篇文章很好地解决了为什么或为什么不的论点：Composite primary keys versus unique object ID field。

我的相对简单的原因是复合键趋于增长：使用借阅示例，如果电影不止一次借阅会发生什么？使用复合方法，您必须将loan_date 添加到复合键。

如果您想跟踪某种类型的再贷款怎么办？然后，您必须有一个第二个表，其中包含贷款表中的所有复合 pk 字段（original_loan_movie_id、original_loan_friend_id、original_loan_date）只是为了引用原始贷款......

Answer 2

在LOAN 表中，您需要保证以下列是唯一的：

• movie_id（替换为copy_id，假设电影有多个副本）
• friend_id
• 贷款日期

...因为我或其他任何人都应该能够多次租借同一部电影。这些也是最有可能被搜索到的列...

考虑到这一点，将名为loan_id 的列定义为表的主键的想法是多余的。 ORM 一直强制使用非复合主键来简化查询...

但它使查询更容易......

乍一看，它使删除或更新特定贷款/等变得更加容易 - 直到您意识到您需要知道适用的 id 值首先。如果您必须根据电影、用户/朋友和日期来搜索该 id 值，那么您最好直接使用该条件。

但是复合键很复杂...

在此示例中，主键约束将确保三列——movie_id、friend_id 和 loan_date——将是唯一的并被索引（如果聚集索引尚不存在，大多数数据库会自动索引主键）使用表的最佳索引。

单独的主键方法意味着loan_id 使用表的最佳索引进行索引（SQL Server 和 MySQL 将它们称为聚集索引，对于 Oracle，它们都只是索引），并且需要额外的复合唯一约束/指数。一些数据库可能需要超出唯一约束的额外索引......所以这使得数据模型更加复杂/复杂，并且没有任何好处：

• 某些数据库（如 MySQL）对可用于索引的空间量进行了限制。
• 主键得到了最理想的索引，但值与表中的数据无关，因此很少使用与主键相关的索引。

结论

我还没有看到单列主键优于复合主键的合理理由。