我想知道我是否可以将人类可读的主键用于相对少量的数据库对象,这些对象将描述大都市地区。
例如,使用“washington_dc”作为华盛顿特区都会区的 pk,或使用“nyc”作为纽约市的 pk。
大量对象将外键到这些都市区对象,我希望能够通过查看他们的数据库记录来判断一个人或企业的位置。
我只是担心,因为我的直觉告诉我这可能是对良好做法的严重犯罪。
那么,我“被允许”做这种事情吗?
谢谢!
我想知道我是否可以将人类可读的主键用于相对少量的数据库对象,这些对象将描述大都市地区。
例如,使用“washington_dc”作为华盛顿特区都会区的 pk,或使用“nyc”作为纽约市的 pk。
大量对象将外键到这些都市区对象,我希望能够通过查看他们的数据库记录来判断一个人或企业的位置。
我只是担心,因为我的直觉告诉我这可能是对良好做法的严重犯罪。
那么,我“被允许”做这种事情吗?
谢谢!
这一切都取决于应用程序 - 自然主键在表面上很有意义,因为它们是人类可读的,并且在向最终用户显示数据时不需要任何连接。
然而,自然主键往往大于INT
(或什至BIGINT
) suragate 主键,并且很少有域没有自然主键更改的危险。举个例子,一个城市改名并不是一件非常罕见的事情。当一个城市的名称发生变化时,您会留下一个需要city
作为外键触及每个实例的更新,或者一个不再反映现实的主键(“数据显示列宁格勒,但它确实是圣彼得堡。” )
总而言之,自然主键:
#1 和 #2 是否被 #3 充分抵消取决于您正在构建什么以及它的用途。
我认为这个问题
很好地概述了您可能做出的权衡。我认为给出的答案是正确的,但它的简洁掩盖了一些重要的想法,你实际上必须做些什么才能找出适合你的东西。
(从那个答案)考虑主键的标准是:
- 独特性
- 不可约性(没有键的子集唯一标识表中的一行)
- 简单(以便关系表示和操作更简单)
- 稳定性(不应经常更改)
- 熟悉度(对用户有意义)
对于它的价值,我通过选择字符串作为主键而遇到缩放问题的次数与我使用自动增量键遇到冗余数据问题的次数大致相同。在我看来,自动增量键出现的问题更糟,因为您通常不会很快看到它们。
主键必须是唯一且不可变的,只要满足这两个要求,人类可读的字符串就可以用作 PK。
在您给出的示例中,这听起来不错,因为城市不会更改其名称(并且在极少数情况下它们会更改名称,那么您可以通过足够的努力来更改 PK 值)。
使用数字 PK 而不是字符串的主要原因之一是性能(另一个是利用自动递增的 ID,请参阅 参考资料IDENTITY
)。如果您预计文本 PK 每秒有超过 100 个查询,那么我会转而使用int
或bigint
作为 PK 类型。当您达到该级别的数据库大小和复杂性时,您往往会停止使用 SSMS 直接编辑表数据并使用您自己的工具,这可能会执行 JOIN,因此您会在与城市的数字 PK 相同的结果集中获得城市名称.
你被允许。
这通常不是最佳做法。
数字 - 首选自动递增键。它们易于维护,并允许对输入表单和其他界面进行编码,用户不必将新字符串视为键...
想象一下:应该是华盛顿,还是washington_dc或dc或washingtondc ..等。