关系数据库设计问题 - 代理键还是自然键？

Question

哪一个是最佳做法，为什么？

a）类型表，代理/人工密钥

外键来自user.type到type.id：

b）类型表，自然键

外键来自user.type到type.typeName：

Answer 1

我相信在实践中，使用natural key很少是最好的选择。我可能会像你的第一个例子那样采用surrogate key方法。

以下是自然关键方法的主要缺点：

• 您的类型名称可能不正确，或者您可能只想重命名该类型。要编辑它，您必须更新将其用作外键的所有表。

• int字段上的索引比varchar字段上的索引要紧凑得多。

• 在某些情况下，可能很难拥有unique自然键，这是必要的，因为它将用作主键。这可能不适用于您的情况。

Answer 2

第一个是未来证明，因为它允许您更改表示类型的字符串而不更新整个用户表。换句话说，您使用surrogate key，为了灵活性而引入了一个额外的不可变标识符。

Answer 3

使用代理键（而不是像名字这样的自然键）的一个很好的理由是，在唯一性方面，自然键不是真正的好选择。在我的一生中，我认识不下4个“克里斯史密斯”。人名不是唯一的。

Answer 4

我更喜欢使用代理键。通常人们会认同并使用自然键，这段时间会很好，直到他们决定要改变价值。然后问题开始了。

Answer 5

您应该总是使用ID号（如果您更改类型名称，则不需要更新用户表），它还允许您保持数据大小，因为充满INT的表很多小于一个满45个字符的varchars。

Answer 6

如果typeName是一个自然键，那么它可能是更好的选择，因为它不需要连接来获取值。

当名称可能发生变化时，您应该只使用代理键（id）。

Answer 7

请给我代替钥匙。

当你需要敲出一些代码时，另一个可能会更容易，但最终会变得更难。回到当天，我的技术老板决定使用电子邮件地址作为主键是一个好主意。毋庸置疑，当人们想改变他们的地址时，它真的很糟糕。

Answer 8

无论何时工作都使用自然键。名称通常不起作用。它们太可变了。

如果您正在发明自己的数据，那么您也可以创建一个综合密钥。如果您要构建其他人或其软件提供的数据数据库，请分析源数据，以了解他们如何识别需要识别的内容。

如果他们一直在管理数据，他们将拥有适用于重要内容的自然键。对于不重要的东西，适合自己。

Answer 9

我认为当你没有任何唯一标识的密钥时，surrgote密钥是有用的，其密钥的值与其主键相关且有意义...而且，surrgote密钥更容易实现，维护开销更少。

但另一方面，surrgote键有时会通过连接表来增加成本。 想想'用户'......我有

UserId varchar(20), ID int, Name varchar(200)

作为表结构。

现在考虑我想跟踪许多表，因为谁在插入记录...如果我使用Id作为主键，那么[1,2,3,4,5..]等将在外表中和每当我需要知道谁正在插入数据我要加入用户表，因为1,2,3,4,5,6没有意义。但是如果我使用UserId作为唯一标识的主键，那么将保存其他外来表[john, annie, nadia, linda123]等，这有时很容易区分和有意义。所以我每次查询时都不需要加入用户表。

但请注意，它需要一些额外的物理空间，因为varchar保存在外部表中，这需要额外的字节..并且当前索引具有显着的性能问题，其中int表现更好而不是varchar