sql - 为主键选择数据类型时应该考虑什么？

Question

当我创建一个新的数据库表时，在选择主键的数据类型时应该考虑哪些因素？

Answer 1

很抱歉这样做，但我发现我对相关问题的回答(您可以查看 this 和 this )可以适用于这个问题。我对它们进行了一些改造...

您会发现很多帖子都涉及这个问题，您所做的每个选择都有其优点和缺点。这些参数通常是指关系数据库理论和数据库性能。

关于这个问题，我的观点很简单:代理主键始终有效 , 而 这些天中的自然键可能并不总是有效 ，这有多种原因:字段太短、规则更改等。

至此，你已经猜到我基本上是 uniqueIdentifier/surrogate 主键团队的成员，即使我欣赏和理解这里提出的论点，我仍然在寻找“自然”的情况 key 比代理更好......

除此之外，支持此基本规则的最重要但总是被遗忘的论点之一与 有关。代码规范化和生产力 :

每次创建表时，我要不要浪费时间

识别其主键及其物理特征(类型、大小)

每次我想在我的代码中引用它时都记住这些特征吗？

向团队中的其他开发人员解释我的 PK 选择？

我的答案是否定的 所有这些问题:

当代理选项为我提供防弹解决方案时，我没有时间尝试确定“最佳自然主键”。

我不想在编写代码时记住我的 Table_whatever 的主键是一个 10 个字符长的字符串。

我不想浪费时间协商自然 key 长度:“好吧，如果您需要 10，为什么不采取 12 以确保安全 ？”。此 “安全起见”争论真的让我很恼火:如果你想留在安全的一边，就意味着你真的离不安全的一边不远了!选择代理:它是防弹的!

所以在过去的五年里，我一直遵循一个非常基本的规则:每个表(我们称之为“myTable”)都有它的第一个字段，称为 'id_MyTable'。这是 uniqueIdentifier 类型。即使这个表支持“多对多”关系，其中字段组合提供了一个非常可接受的主键，我更喜欢创建这个 'id_myManyToManyTable' field 是一个 uniqueIdentifier，只是为了遵守规则，因为，最后，它没有伤害。

主要优点是您不必再关心代码中主键和/或外键的使用。获得表名后，您就知道 PK 名称和类型。一旦您知道在您的数据模型中实现了哪些链接，您就会知道表中可用外键的名称。

如果你仍然想在你的 table 上的某个地方有你的“自然 key ”，我建议你按照标准模型来构建它，比如

Tbl_whatever

   id_whatever, unique identifier, primary key
   code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed
   .....

其中 id_ 是主键的前缀，code_ 用于“自然”索引字段。有些人会争辩说 code_ 字段应该设置为唯一的。确实如此，并且可以通过 DDL 或外部代码轻松管理。注意很多“自然”键是计算出来的(发票号)，所以已经通过代码生成了

我不确定我的规则是最好的。但这是一种非常有效的方法!如果每个人都在应用它，例如，我们将避免浪费时间回答此类问题!