Question

我的问题或多或少与this one相反：当使用序列作为代理时，为什么会想要在关系中找到自然的主键似乎更容易。

BradC在his answer中提到了{{3}}相关问题，即选择主键的标准是唯一性，不可简化性，简单性，稳定性和熟悉度。在我看来，使用序列牺牲了最后一个标准，以便为前四个提供最佳解决方案。

如果我认为这些标准是正确的，我可以将我的问题重新表述为：在哪种情况下，人们会认为通过寻找一种既熟悉的独特，不可简化，简单和稳定的密钥来使一个人的生活复杂化是有利的？ / p>

Answer 1

从查找表中获取有意义的值，而不进行不必要的连接。

示例案例：garments引用颜色查找表，其中包含自动增量主键。获取颜色名称需要加入：

SELECT c.color
FROM garments g
JOIN colors c USING (color_id);

更简单的示例：colors.color本身是该表的主键，因此它是引用它的任何表中的外键列。

SELECT g.color
FROM garments g

Answer 2

答案是数据完整性。根据定义，数据库外部的业务域中的实体实例是可识别的事物。如果您未能在数据库中为他们提供外部的，真实世界的标识符，那么该数据库很难正确地模拟现实。

自然键[1]确保数据库中的事实可以通过您尝试建模的现实中的实际事物来识别。它们是用户在操作和更新数据库中的数据时所依赖的手段。强制执行这些键的约束是业务规则的实现。如果您的数据库要准确地为业务域建模，那么自然键不仅是理想的，而且是必不可少的。如果你怀疑那么你还没有做足够的业务分析。只要询问客户，如果他们只看着满是重复数据的屏幕，他们认为他们的业务会如何运作！

[1]我建议将它们称为 business 键或域键，而不是自然键。即使它们的含义完全相同，它们也更合适，更少重载。

Answer 3

您通常需要确定数据上的唯一键是什么，因为您仍然需要能够确保数据不重复。

合成键的强度在于它允许将来可以修改唯一自然键的值，而不需要更新子记录。

因此，您并没有真正使用合成主键跳过设计中的“识别关键”部分，而是让您自己避免价值变化的可能性。

Answer 4

以下是使用自然主键的好处：

如果您需要对任何列进行唯一约束，那么如果您不希望在其中接收任何null值，则使其成为主键将满足该要求。因此，无论如何，它可以节省您的1个额外密钥的成本。
在某些RDBMS中，您声明为主键的键会自动在该列上创建btree索引，如果您根据访问模式创建自然主键，则就像蛋糕，因为现在您用一块石头拍了两枪。通过在where子句中使用有意义的主键，可以节省额外索引的成本，并使查询速度更快。
最后但并非最不重要的一点是，您将可以节省一个额外的列/键/索引的空间。

找到自然主键有什么好处

4 个答案: