我正在与之合作的团队决定使用varchar主键创建一个表。此表由此主键上的另一个表引用。
我习惯按照我在大学学到的东西来创建一个整数主键。我已经读过使用整数主键提升性能。
问题是我不知道创建整数主键的任何其他原因。你有什么提示吗？
答案 0 :(得分：41)
VARCHAR与INT并没有多大关系。什么是访问模式。
从绝对意义上讲，更宽的密钥总是比窄密钥更差。这种类型绝对不重要，重要的是宽度。虽然与INT相比，很少有类型可以在狭窄的范围内击败INT，因此INT通常仅通过4字节宽的事实赢得该参数。
但真正重要的是选择群集键。通常与主键混淆，两者代表不同的概念，并且不需要重叠。这里有更详细的讨论Should I design a table with a primary key of varchar or int?群集密钥的选择只是表格设计中最重要的决定，而INT identity(1,1)的机械应用可能只是最大的错误。以下是访问模式的问题：
总的来说，有许多访问模式可以通过使用INT IDENTITY集群密钥来破坏。因此，在开始应用cookie切割器解决方案之前，可能需要进行一些分析......
更一般的指导原则：
您发现没有主键设计指南，因为主键不是存储设计的问题，而是建模的问题，完全是域驱动的。
答案 1 :(得分：38)
主键应该表示行的标识，不应随时间变化。
我假设varchar是某种自然键 - 例如实体名称，电子邮件地址或序列号。如果您使用自然键，则有时可能会发生键需要更改，例如：
通过使用代理键，您可以避免因必须更改主键而导致的问题。
答案 2 :(得分：24)
我有点失望，因为我 创建整数主要的习惯 关键（按照一些老师的说法） 我在大学）。我读了很多 关于性能的文档 使用整数主键进行提升。
有一个术语：confirmation bias：
“也称为确认偏见或myside偏见”是人们倾向于支持确认其先入之见或假设的信息，而不管它们是否属实。这导致人们有选择地收集新证据，以偏见的方式解释证据，或选择性地从记忆中回忆信息。“
当然，你的第一反应就是说，“但那不是真的！”是的，你会说'因为你有偏见;）[舌头牢牢地嵌在脸颊上]
这是一个典型的例子：说你的动物学教授告诉你所有的天鹅都是白色的，当然，你和你的朋友遇到的所有天鹅都是白色的。现在让我们说晚年生活中一位同事表达了这样一种观点，即也许有一种黑天鹅这样的生物。什么？！这不是你所教的。你的世界震撼了！你立即出去进行天鹅调查，你就会计算出1000只白天鹅和零天鹅。证明！如果你发现了10,000只白天鹅，那么假设“所有天鹅都是白色的”将是十倍真实，对吧？
另一种方法是暂时忘记白天鹅并尝试寻找黑天鹅。也许在阳光明媚的Dawlish？海边度假？
我真的不是故意不尊重;你承认读了很多关于你被告知的事情，这确实赢得了我的尊重。所以这是一个挑战：尝试找到不必在表中添加整数列的情况。
以下是一些提示和破坏者：未被其他表引用的表;单列'所有键'查找表; “小”表没有被查询太多：）
以下是您可能要调查的其他一些相关主题：
“主键”中的“主要”一词是否具有很多含义，或者给定表中的所有键是否相等？
'好'键有什么特质？ （例如，如果一个键的值是不可变的，或者稳定性是否足够好？）
是一个整数列作为人工键添加到表中（perhpas因为可用的自然键不够“好”）或作为代理键（可能是为了提高其他'好'自然键的性能）？< / p>
当代理密钥在性能方面被添加到表格中时，这是实际测量的效果还是仅仅是感知效果（即过早优化）？
代理键是否应出现在逻辑业务模型中，还是仅用于实现？
总是做一些事情（例如，将一个整数列添加到表格中），而不是每次都吸引大脑，这是一个好主意吗？ ;）
[免责声明：我是天生的主要倡导者并避开代理人。对我而言，它们就像非规范化一样：只有当你必须这样做时才会这样做，通常是因为性能问题（特定的和可证明的），故障在别处（糟糕的SQL产品版本，此时无法修复的逻辑设计缺陷等） ）。代理人不应该出现在逻辑商业模式中。我有时需要一个人工识别器，甚至暴露出逻辑商业模式。]