数据库已规范化，但生成的复合键包含 20 列答案

【问题标题】：Database is normalized but resulting composite keys contain 20 columns数据库已规范化，但生成的复合键包含 20 列
【发布时间】：2011-02-20 12:57:40
【问题描述】：

问题是存在非常大的关系，以至于在规范化后它们有 20 个主键（复合键），它们实际上是外键。

这些必须声明为主键才能唯一地标识关系。这是正确的吗？

【问题讨论】：

【解决方案1】：

听起来您的数据库很大并且有很多关系；简化主键情况可以做的一件事是将单个列定义为每个表的主键，并使用自动递增的 int 或 guid 数据类型。这样您就可以确保唯一性，并且您的外键至少独立于您的主键。

【讨论】：

【解决方案2】：

我无法可视化包含 20 个表且与一个表相关的设计。

如果不查看您的数据设计，我无法判断，但听起来您设计的是分层数据库，而不是关系数据库。

【讨论】：

不，发生了。我曾经有一个系统，有 200 个表引用一个。 CMS（Web CMS），其中一个表是“ContentItem”，其中包含项目的层次结构。几乎所有“都是内容项目”，包括商店优惠、其中的价格、安全性、用户等。
@TomTom：是的，ContentItem 是一个查找表。但是有一个表与其他 20 个表有关系，并且与其他 20 个表有一个外键，这是不寻常的。我无法想象这样的设计。
对象层次结构 - 看起来相同。实际上，使用 O/R 映射器并不难——几乎所有东西都继承自 ContentItem。现在我在财务应用程序中有类似的事情。表：ops.Item - OperationsItem。在这张表上我们处理安全问题，许多不同的表都有一个指向“他们的”操作的键。项目（帐户等 - 甚至用户，谁可以编辑用户等）。
@TomTom：我很难想象您的财务示例。这可能是我作为数据建模师的局限性。
好吧，想象一下你有一个像windows这样的安全系统（权限、用户、授予的权限）和各种可以拥有权限的对象。最后你有一个表“SecuredObject”——基本上——会有很多对象指向它。因为您需要该表来对这些对象的权限进行建模。

【解决方案3】：

如果你说你有“确实是外键但需要声明为主键的外键”，那么你实际上表明你缺乏进行数据库设计的能力、技能和权限。

外键和“主”键是完全不同的概念，即使是对数据库设计领域稍有了解的任何人都不太可能将它们混淆。

也许你可以再试一次，解释一下你的意思。

【讨论】：

【解决方案4】：

首先，永远不要使用复合键。他们是一种糟糕的技术。它们很慢，并且在更改时维护起来简直就是一场噩梦。

如果您需要两个或多个字段的唯一性，则不需要主键，您需要唯一索引。使表的 PK 成为代理键（最好是 int）。

如果尝试创建一对一关系的表，可以使用父表的PK作为子表的PK，并在表之间设置PK_FK关系；但是，需要 20 个单独的一对一表是不寻常的。

【讨论】：

你的建议是矛盾的，不是吗？通过建议您需要一个“唯一索引”，我理解您的意思是应该以这种方式强制执行复合键约束。因此，它仍然是事实上的复合键。复合键没有任何问题——它们是一件好事。但在我看来，如果通过唯一约束（例如 SQL UNIQUE 或 PRIMARY KEY 约束）显式创建它们而不是通过索引隐式创建它们会更好。这是假设所讨论的 DBMS 支持唯一约束。
唯一索引不是复合键。它不用于与其他表相关，因此根本不是 KEY。您不想要复合键的原因是，在与其他表相关时，您需要使用尽可能小的键来提高性能。你还需要一些值永远不会改变的东西，这对于复合键来说是极其罕见的。我永远不会考虑使用不允许唯一索引的数据库，那只是一个玩具而不是真正的数据库。
键不只是“用于与其他表相关”的东西。候选键是一组列属性，要求是唯一的并且是不可约的。复合键是具有多个属性的任何候选键。因此，复合键对于有效的数据库设计是必不可少的。是否在另一个表中引用了任何此类键是另一个问题。此外，组合键很可能小于单个属性键。大小当然是一个因素，但它不是唯一的，而且很少是最重要的。