如果我使用ID nr：s而不是VARCHARS作为外键，会更好吗？ 是否更好地使用ID nr：s而不是VARCHARS作为主键？ ID ID我的意思是INT！
这就是我现在所拥有的：
category table:
cat_id ( INT ) (PK)
cat_name (VARCHAR)
category options table:
option_id ( INT ) (PK)
car_id ( INT ) (FK)
option_name ( VARCHAR )
我有这个想法：
category table:
cat_name (VARCHAR) (PK)
category options table:
cat_name ( VARCHAR ) (FK)
option_name ( VARCHAR ) ( PK )
或者我在这里想错了？
答案 0 :(得分：30)
VARCHAR用于任何KEY的问题在于它们可以容纳WHITE SPACE。空格由任何非屏幕可读字符组成，如空格标签，回车等。当你开始寻找为什么表没有返回末尾有额外空格的记录时，使用VARCHAR作为键会让你的生活变得困难他们的钥匙。
当然，您 CAN 使用VARCHAR，但您必须非常小心输入和输出。它们也会占用更多空间，并且在进行查询时可能会更慢。
整数类型包含10个有效字符的小列表， 0,1,2,3,4,5,6,7,8,9 。它们是用作密钥的更好的解决方案。
如果您希望获得更快查找的优势，您可以始终使用基于整数的键并使用VARCHAR作为UNIQUE值。
答案 1 :(得分：11)
当我从事设计工作时，我会问自己：我能否保证这些数据中的任何内容都是非NULL，唯一且不变？如果是这样，那么候选人就成了主键。如果没有，我知道我必须生成一个要使用的键值。那么，假设我的候选键恰好是VARCHAR，那么我会查看数据。它的长度是否相当短（意思是说，20个字符或更少）？或者VARCHAR字段是否相当长？如果它很短，那么它可用作一个键 - 如果它很长，也许最好不要将它用作键（尽管如果它考虑成为主键，我可能不得不索引它）。至少我担心的一部分是主键必须被索引，并且可能被用作来自其他表的外键。 VARCHAR字段的比较往往比数字字段（特别是二进制数字字段，如整数）的比较慢，因此使用长VARCHAR字段作为键可能会导致性能降低。 YMMV。
答案 2 :(得分：10)
我的2美分：
从性能角度来看，使用CHAR或VARCHAR作为主键或索引是一场噩梦。
我测试了复合主键（INT + CHAR，INT + VARCHAR，INT + INT），到目前为止INT + INT是最佳性能（加载数据仓库）。如果你只保留数字主键/索引，可以说大约两倍的性能。
答案 3 :(得分：4)
如果您将类别名称设为ID，则在决定重命名类别时会出现问题。
答案 4 :(得分：3)
我想说将 VARCHAR 用作 PRIMARY和FOREIGN KEYS 是可以的。
唯一的问题我可以预见，如果你有一张桌子，让我们说乐器（分享乐器），你创建 PRIMARY / FOREIGN KEY 为 VARCHAR < / em>，并且 CODE 发生了变化。
这种情况确实发生在证券交易所，并要求您重命名对此 CODE 的所有引用，其中ID nr不会要求您这样做。
总而言之，我认为这取决于您的预期用途。
修改
当我说CODE时，我的意思是Ticker Code，比如说我或任何其他分享。这些代码可能会随着时间的推移而改变，让我们看看Dirivative / Future乐器。
答案 5 :(得分：3)
使用int，你可以在4个字节中存储多达20亿个varchars，你不需要有10个字节左右来存储它，如果你使用varchars也有2个字节的开销
所以现在你在每个PK和FK + 2字节varchar开销中加上6个额外的字节
答案 6 :(得分：1)
这两种方法都没有错，虽然这个问题可能会开始通常的论证更好：自然或代理键。
如果您使用CHAR或VARCHAR作为主键，您最终会在某些时候将其用作forign键。正如@astander所说，它取决于你的数据以及你将如何使用它。