使用复合/复合主键有哪些缺点？

Question

使用复合/复合主键有哪些缺点？

Answer 1

1. 可能导致更多规范化问题（2NF，“请注意，当1NF表没有复合候选键（候选键由多个属性组成）时，表自动为2NF “）
2. 更多不必要的数据重复。如果组合键由3列组成，则需要在每个表中创建相同的3列，并将其用作外键。
3. 通常可以在代理键（read about their advantages and disadvantages）
的帮助下避免
4. 我可以想象一个复合键的好方案 - 在表示N：N关系的表中，如Students - Classes，中间表中的键将是（StudentID，ClassID）。但是如果你需要存储关于每一对的更多信息（比如一个班级中学生的所有分数的历史记录），那么你可能会引入一个代理密钥。

Answer 2

复合键本身没有任何问题，但理想情况下主键应尽可能小（根据所需的字节数）。如果主键很长，那么这将导致非聚集索引膨胀。

请记住，主键中列的顺序很重要。第一列应尽可能具有选择性，即尽可能“独特”。搜索第一列将能够搜索，但只搜索第二列必须扫描，除非第二列上还有非聚集索引。

Answer 3

我认为这是合成密钥辩论的一种特殊化（是否使用有意义的密钥或任意合成主密钥）。出于多种原因，我几乎完全退出本次辩论的综合关键方面。这些是一些更相关的：

• 你必须保持受抚养的孩子 表格在foriegn键的末尾 最新。如果你改变了 其中一个主键的值 字段（可能发生 - 见 下面）你必须以某种方式改变 所有依赖表在哪里 他们的PK值包括这些 领域。这有点棘手 因为改变键值会 使FK关系无效 儿童表所以你可以（依赖 关于约束验证选项 在您的平台上可用）必须 诉诸抄袭的伎俩 记录到新的并删除 旧记录。

• 在深层架构上，密钥可以获得     很宽 - 我见过8列     一次。

• 主键值的更改可以是     在ETL中识别很麻烦     加载系统的进程。     我曾经有过的例子     看到的是一个MIS应用程序     从保险中提取     承销制度。一些     政策条目的场合     改变了客户的重用     政策标识符。这是一个     部分主键     表。当这发生时     仓库负载不知道是什么     旧的价值是如此无法比拟     它的新数据。开发者     不得不去审核     记录以识别更改的值。

非合成主键的大多数问题都围绕着记录的PK值发生变化时的问题。非合成值的最有用的应用程序是打算使用数据库模式的地方，例如M.I.S.报表编写者直接使用表的应用程序。在这种情况下，为方便起见，可以合理地将具有固定域（如货币代码或日期）的短值直接放在桌面上。

Answer 4

我建议在自然复合键上使用唯一的非空约束的情况下生成主键。

如果您使用自然键作为主键，那么您很可能必须在外键引用中引用这两个值，以确保您正在识别正确的记录。

Answer 5

以带有两个候选键的表为例：一个简单（单列）和一个复合（多列）。你在这种情况下的问题似乎是，“如果我选择将一把钥匙提升为'主要'并选择复合钥匙，我可能会遭受哪些不利影响？”

首先，考虑一下你是否真的需要提升一个密钥：“SQL中PRIMARY KEY的存在似乎是某种历史性事故。根据作者Chris Date最早的SQL版本没有任何关键限制，PRIMARY KEY后来才被添加到SQL标准中。标准的设计者显然接受了发明它的EFCodd这个术语，尽管那时Codd的原始概念已被抛弃了！ （Codd最初提出外键必须只引用一个键 - 主键 - 但这个想法被遗忘和忽略，因为它被广泛认为是一个无意义的限制）。 [来源：David Portas' Blog: Down with Primary Keys?

其次，您应该选择什么标准来选择表中的哪个键应该是“主要”？ 在SQL中，键PRIMARY KEY的选择是任意的和产品特定的。在ACE / Jet（又名MS Access）中，两个主要且经常相互竞争的因素是您是否希望使用PRIMARY KEY来支持磁盘上的群集，或者您是否希望包含密钥的列在“关系”中显示为粗体MS Access用户界面中的图片;我认为索引策略胜过漂亮的图片我占少数:)在SQL Server中，您可以独立于PRIMARY KEY指定聚集索引，并且似乎没有提供特定于产品的优势。唯一剩下的优势似乎是在SQL DDL中创建外键时可以省略PRIMARY KEY的列，这是一个SQL-92标准行为，无论如何对我来说似乎没什么大不了的（也许是他们添加到标准中的另一个因素，因为它是SQL产品中已经普及的一个功能？）因此，它不是寻找缺点的情况，而是应该看看优势，如果有的话，您的SQL产品会提供PRIMARY KEY。换句话说，选择错误密钥的唯一缺点是你可能错过了一个给定的优势。

第三，您是否提到使用人工/合成/代理键在您的物理模型中从您的逻辑模型中实现候选键，因为您担心如果在外键中使用自然键，将会有性能损失表加入？这是一个完全不同的问题，很大程度上取决于你对SQL中自然键问题的“宗教”立场。

Answer 6

需要更多特异性。

太过分了，它可能会过度复杂化插入（每个键必须存在）和文档，如果不完整，你的联合读取可能会被怀疑。

有时它可以指示一个有缺陷的数据模型（复合键真的是数据所描述的吗？）

我不相信会有性能成本......它真的很容易出错。

Answer 7

1. 当您在图表上显示时，可读性较差
2. 在查询时使用它的连接次数较少 可读
3. 在foregein键上使用它时 你必须添加一个检查约束 关于所有属性必须是 null或not null（如果只有一个 null未检查密钥）
4. 使用时通常需要更多存储空间 作为外键
5. 某些工具无法管理复合材料 键

Answer 8

使用复合主键的主要缺点是，你会混淆典型的ORM代码生成器。