用户区域设置关联/关系 - 区域设置代码上的外键？

Question

我有2个表：Users和Locales。

Locales(id, name, code)

Locales.name是locale的英文名称（例如'Spanish'），Locales.code是locale的5 char代码（例如'en_us'）。每个用户都应该有一个区域设置。我想到了两个选择：

1. 用户表格的LocaleId列为FK Locales.id。
2. 用户表格将locale (string)列作为FK到Locales.code列

哪种方法会更好？请注意，我将不得不在某些区域设置中搜索用户，在区域设置字段等其他表上执行某些连接。

Answer 1

在您的表中，您在ID中有（我假设的）系统生成的值。这是你的代理钥匙。但是，您在Code中也有一个自然键值。是的，您可以在Code上定义唯一约束，以便外键可以引用它。但是，如果你这样做，为什么不继续把它作为你的主要钥匙呢？

在这个问题上仍然存在着长期存在的争论。

有一方面对问题 - 这是一个很好的案例 - 它必须是所有案例中的所有案例方面，并要求所有表格都有一个代理键。

我不同意。让我们看看如果您完全丢弃ID字段并使Code成为表格的PK，会发生什么。

好的一面：

1. 关键价值本身对几乎所有看到它的人都有意义。因此，查看Users表就足以说明他们喜欢哪种语言。除了我的祖母以外，是否有人不知道“en_gb”中的“en_us”？很多时候，您甚至不必加入Locales表 - 在大多数情况下您已经拥有足够的信息。
2. 你已从表中删除了一个额外的字段。简化而不牺牲功能总是好的。
3. 为每个插入生成保证的唯一值确实需要一些系统开销。在这种情况下，这不会很重要，因为一旦填充了Locales表，它就应该非常稳定。

在负面：

1. 通过数值连接比字符串稍微有效。差别很小，但有。
2. 您可以依靠Microsoft多少来保持当前值稳定并且不做任何更改，也许可以将“en_gb”更改为“en_uk”或类似的内容？一旦建立了对关键值的引用，更改该值可能是一个非常大的挑战。
3. 即使您确定现有值不会改变，未来的值是否会超过5个字符？这不是实践的固有缺点，只是您的特定实现。 ：）
4. 代理（通常为整数）往往小于自然键（通常是字符串）。虽然密钥表中只有一个列，但在引用表时可能会有更大的FK列。

那么哪种情况更适合您的特定情况？

我不知道。

您和您的团队必须权衡利弊，做出自己的决定。