这不是关于在任何给定表中使用人工自动增量键与使用多字段“主键”相比的好处或其他方面的问题。任何想要搜索它们的人都可以轻松找到该讨论（或争论）并做出决定。
这个问题更多地是关于键的性能（或缺乏）
我是一名数据库管理员，当我创建表时，我尝试为表使用“自然”键。通常，这是一组 2,3，有时是 4 个字段，它们充当给定表的主键。通常，这些字段本质上是 Varchar，但很短（最多 10 或 15 个字符）。就我个人而言，我尽量让它们更短！
我的问题是这个。
想象一下，我有一个包含人口统计数据的表。我可以确保每一行都具有唯一性的唯一方法是使用 FirstName FamilyName DateOfBirth PlaceOfBirth 的字段
（您可能想知道为什么我包括“出生地”，我知道另一个人（曾经住在附近 - 相同的电话号码，不同的拨号代码）与我分享了所有这些详细信息（我假设出生地不同，但我想我可以使用 MothersMaidenName ;) )
所以现在我有一个有趣的问题。
我可以使用一个更短的字段，该字段是通过连接 4 个主要字段示例中的信息创建的：DateOfBirth FirstName 的前 2 个字符 FamilyName 的前 2 个字符 PlaceOfBirth 的前 2 个字符
我的问题是这个。
在什么时候，字段的串联会比直接使用字段提供性能改进，即有多少列。
我从搜索中了解到，大多数 DBMS 都有一个“理论上的最大大小限制”，这取决于所创建的 B 树。我假设我在主键的长度/大小方面没有达到这个限制。
我考虑使用这种类型的“人为”键的原因是：连接列中的信息很可能足以识别记录，而无需提取所有主键字段（这对性能更好还是没有？与使用所有 4 个主键字段相比有何不同？）
这显然是一个相当“理论”的问题，但我考虑过在一个最终有 4 个 varchar 字段的表上进行这种连接，很明显，唯一性将通过仅使用缩短版本来描述。显然，首先要努力创造这个领域，但在其他人看来，这种努力是否值得，在什么时候它会变得更有趣。
我已经搜索过这个问题，但我从未发现直接提出这个问题，它以“自然”或“人工”主键讨论的形式出现。
当然，如果这感觉像是“自然”或“人工”的关键讨论，请随意说出来。我的感觉是，这个“人为”的钥匙会提供两者的优点。有没有人在现实世界的解决方案中使用过这个想法？
预先感谢您的想法。
大卫
编辑。我刚找到这个线程
它似乎涵盖了类似的领域，我必须承认我没有想过将我的专栏“散列”在一起（主要是因为它们本质上很短），但我确实喜欢这个想法。我想你可以这样做并散列整行！
编辑2。
我回到这个问题只是想看看答案是否有任何变化或额外的评论。我已决定接受回复，但要注意的是，我发现所有回复对讨论的内容都有帮助。
我会斜着回答...
自然键始终是自然键，应使用唯一约束或索引强制执行。这是从建模阶段流出的“主键” 。
自动编号/身份代理键的选择在实施阶段很重要，因为您的聚集索引有好的和坏的选择（例如：SQL Server、Sybase、MySQL InnoDB、Oracle IOT）。
也就是说，主键与您的聚集索引正交：不要混淆这两个问题
在这方面，我建议使用人为的键不会增加使用自动编号/身份列的价值。您从自然键中丢失数据，可能不是唯一的，同样不透明。
FWIW，我在需要时也使用代理键和复合键：
注意：这里假设每个表都需要一个聚集索引
dba.se 相关：SQL Server 主键/聚集索引设计决策
| 归档时间： |
|
| 查看次数： |
3727 次 |
| 最近记录： |