可以安全地在SQL中使用人类可读的主键吗？

Question

我想知道我是否可以将人类可读的主键用于相对较少数量的数据库对象，这些对象将描述大都市区域。

例如，使用“washington_dc”作为华盛顿特区都市区的pk，或纽约市的“nyc”。

Tons 对象将被外键键入这些都市区域对象，我希望能够通过查看他们的数据库记录来判断一个人或企业的位置。

我只是担心，因为我的直觉告诉我这可能是违反良好做法的严重罪行。

那么，我“允许”做这种事吗？

谢谢！

Answer 1

这完全取决于应用程序 - 自然主键在表面上具有很强的意义，因为它们是人类可读的，并且在向最终用户显示数据时不需要任何连接。

但是，自然主键趋于大于INT（甚至BIGINT）suragate主键，并且很少有域没有危险有一个自然的主键变化。举个例子，一个改名的城市并不是一个非常罕见的事件。当一个城市的名称发生变化时，你会得到一个更新，需要触及city的每个实例作为外键或者不再反映现实的主键（“数据显示列宁格勒，但它确实是圣彼得堡。“）

总而言之，自然主键：

1. 占用更多光盘空间（当时大多数）
2. 更容易发生变化（在多数案例中）
3. 更具人性化（只要它们不会改变）

＃1和＃2是否被＃3充分抵消取决于你正在构建什么以及它的用途。

Answer 2

我认为这个问题

What are the design criteria for primary keys?

非常好地概述了您可能会做出的权衡。我认为给出的答案是正确的，但它的简洁性掩盖了你实际需要做的一些重要的思考，以找出适合你的方法。

（从答案） 考虑主键的标准是：

  

  
• 唯一性
  
• 不可简化性（密钥的任何子集都没有唯一标识表中的行）
  
• 简单（以便关系表示和操作可以更简单）
  
• 稳定性（不应经常更改）
  
• 熟悉（对用户有意义）
  

对于它的价值，通过选择字符串作为主键，我在缩放方面遇到问题的次数与我使用自动增量键的冗余数据出现问题的次数大致相同。在我看来，自动增量键出现的问题更糟糕，因为你通常不会很快看到它们。

Answer 3

主键必须是唯一且不可变的，只要符合这两个要求，人类可读的字符串就可以用作PK。

在你给出的例子中，听起来不错，因为城市没有改变他们的名字（在极少数情况下他们这样做，你可以用足够的努力改变PK值。）

使用数字PK而不是字符串的主要原因之一是性能（另一个是利用自动递增ID，请参阅IDENTITY）。如果您预计文本PK每秒会有超过一百个查询，那么我会转而使用int或bigint作为PK类型。当您达到该数据库大小和复杂程度时，您倾向于停止使用SSMS直接编辑表数据并使用您自己的工具，这可能会执行JOIN，因此您将获得与城市数字PK相同的结果集中的城市名称

Answer 4

你被允许。

这通常不是最佳做法。

数字 - 首选自动递增键。它们易于维护，允许对输入表单和其他接口进行编码，用户无需将新字符串视为关键字...

想象一下：它应该是华盛顿，还是华盛顿或华盛顿特区或者华盛顿等等。