在代理键的情况下单独的表？

Posted 2023-02-26

【中文标题】在代理键的情况下单独的表？

【英文标题】：Separate table in case of surrogate key?

【发布时间】：2010-02-04 19:22:11

【问题描述】：

我一直在阅读 Stack Overflow 和其他网站上关于复合键与代理键的激烈辩论，尽管对给出的一些论点感到困惑，但我觉得我知道每个论点的优缺点。

我很想选择代理键，但现在我有另一个问题。让我解释一下我的情况。我有一个由 5 个整数组成的表，这些整数组成了一个唯一的组合，并且我有几个表引用了这个实体。现在所有表都包含完整的 5 个字段，并且所有 JOIN 操作都必须将所有 5 个字段作为连接标准。现在我添加了一个代理键。但是我应该从所有表中删除所有 5 个字段以支持引用“主”表的代理外键吗？

我不确定是否要这样做，因为这 5 个字段中的每一个字段都经常单独用作其他表中的选择标准。我以某种自然顺序在它们上定义了索引，以便选择操作执行得更快。如果我将所有 5 个字段迁移到一个单独的表中，恐怕当我想选择前三个字段时，我将不得不定义一个 JOIN 并从中选择，但不会定义任何索引在那个 JOIN 上，因为它刚刚生成，我将遭受性能损失。

或者我应该以某种方式为每个表定义一个 VIEW，包括 5 个键，并在其上建立索引？

我感到困惑，在输入了所有这些之后，我倾向于再次使用自然键。 帮忙？

【参考方案1】：

我建议有一个表，其中包含 5 个唯一字段 + 代理 PRIMARY KEY。在该表中，您可以在每个字段上创建索引 + 在 5 个字段上创建唯一约束。然后，您将只有 1 列，而不是其他表中的 5 个字段。

【讨论】：

嗯，是的，然后我可以在那个表上放置一个索引并与其他表连接，这样我的过滤器也会很快。我将尝试这两种方法并比较性能。

【参考方案2】：

除非您有一个非常具体的目标来引入代理键，否则我可能会不理会它，只要它适合您。