组合代理外键作为 PK 或单独的代理键

Question

下图显示了两种可供选择的数据库设计。一个由两个外键组合而成，一个具有自己的代理键。第二个选项将对 DanceGroupId 和 StudioId 具有复合唯一约束，因此不能输入两个相同的约束。我一直采用第一个设计，但是在用 C# 构建我的类之后，如果我可以在我的所有表上放置一个通用的非复合代理键，它将有助于 C# 代码重用。在数据库设计方面，在像 Booking 这样的表上使用代理而不是组合有什么负面影响？

我不是在这里寻找一般的复合与代理辩论，它略有不同，因为我在选项一中的复合键是由外键组成的。据我所知，代理比自然键更受青睐，因为它们不依赖业务相关数据。在这种情况下，这不是一个问题，也从来没有过，但是我以前从未在“中间”表上看到过这种方法。像在第二个选项中那样实现它似乎是合理的，但我想知道我是否遗漏了什么。

Answer 1

当您不需要时定义伪键的可能负面影响：

• 每行一个多余的整数会使行更宽，占用更多磁盘和内存空间。

• 更多争用机制用于生成不必要的伪键值。

• 破坏聚集索引的使用以获得额外的性能。定义集群索引以匹配最常见的查询是有意义的。例如，如果您的查询最常包含有关 StudioId 的条件，则将其设为聚集索引的第一列。在某些 SQL 实现（例如 MySQL）中，主键始终用作聚集索引。在其他一些 SQL 实现中，您可以选择另一个二级唯一键作为聚集索引。