可以对主键使用字符值吗？答案

【问题标题】：Is it ok to use character values for primary keys?可以对主键使用字符值吗？
【发布时间】：2010-10-01 12:46:58
【问题描述】：

与使用基于字符的字段相比，在数据库表中使用唯一的数字 ID 字段是否有性能提升或最佳实践？

例如，如果我有两个表：

运动员

id ... 17, 姓名 ... Rickey Henderson, teamid强> ... 28

团队

teamid ... 28, teamname ... 奥克兰

如果 teamid 是“OAK”或“SD”而不是“28”或“31”，则包含数千名球员的运动员表会更容易阅读。让我们理所当然地认为 teamid 值将在角色形式上保持独特和一致。

我知道您可以使用字符，但是出于某种原因，索引、过滤等是否是个坏主意？

请忽略规范化参数，因为这些表比示例更复杂。

【问题讨论】：

合成与自然键参数 rehash，也是 stackoverflow.com/questions/144109/… 的副本，另请参阅 stackoverflow.com/search?q=synthetic+key
值得注意的是，您说的是字符字段，而不是 MSSQL 的“文本”类型，我认为它是不可索引的。

标签： database database-design optimization schema normalization

【解决方案1】：

我发现从长远来看，主键是无意义的数字不会让人头疼。

【讨论】：

我同意。唯一的例外是当您必须拥有一个跨多个表必须唯一的主键时。在这种情况下，请使用序列（如果是 oracle 或 postgresql）或 GUID（如果是 MS Sql Server）。

【解决方案2】：

文字很好，因为你提到的所有原因。

如果字符串只有几个字符，那么无论如何它都几乎是一个整数。使用字符串的最大潜在缺点是大小：数据库性能与需要多少磁盘访问有关。例如，将索引设置为两倍大，可能会造成磁盘缓存压力，并增加磁盘寻道次数。

【讨论】：

【解决方案3】：

我不会使用文本作为您的密钥 - 将来当您想更改某个团队的团队 ID 时会发生什么？您必须在整个数据中级联该键更改，而这正是主键可以避免的事情。另外，虽然我没有任何经验证据，但我认为 INT 键会比文本键快得多。

也许您可以为数据创建视图，使其更易于使用，同时仍使用数字主键。

【讨论】：

【解决方案4】：

我将继续使用您的示例。道格说文本没问题时是正确的。即使对于具有 3 个字母代码的中型（~50gig）数据库作为主键也不会杀死数据库。如果它使开发更容易，减少另一个表上的连接，这是一个用户将输入的字段......我说去吧。如果它只是您在页面上显示的缩写，或者因为它使运动员表看起来很漂亮，请不要这样做。我认为关键是“这是用户输入的代码，而不是从列表中选择的代码吗？”

让我举一个例子，说明我何时使用文本列作为键。我正在制作处理医疗索赔的软件。在索赔全部数字化后，人类必须查看索赔，然后为它选择一个代码，指定它是什么类型的索赔。有数百个代码......这些人都记住了它们或婴儿床单来帮助他们。他们多年来一直在使用这些相同的代码。使用 3 个字母的密钥让他们轻松完成索赔处理。

【讨论】：

【解决方案5】：

我建议对主键使用整数或大整数。好处包括：

这允许更快的连接。
在主键中没有语义含义允许您更改具有语义含义的字段，而不会影响与其他表的关系。

您始终可以使用另一列来保存“OAK”和“SD”的 team_code 或其他内容。还有

【讨论】：

【解决方案6】：

标准答案是使用数字，因为它们的索引速度更快；无需计算哈希或其他任何东西。

如果您使用有意义的值作为主键，如果团队名称发生更改，则必须通过您的数据库对其进行全部更新。

满足以上，但仍使数据库直接可读，

使用数字字段作为主键
立即创建一个视图 Athlete_And_Team 来连接 Athlete 和 Team 表

然后您可以在手动浏览数据时使用视图。

【讨论】：

【解决方案7】：

您是在谈论您的主键还是聚集索引？您的聚集索引应该是您最常用于唯一标识该行的列。它还定义了表中行的逻辑顺序。聚集索引几乎总是您的主键，但在某些情况下它们可能会有所不同。

【讨论】：