问使用char作为主键/外键是不可行的吗？

EN

性能并不是真正的主要问题，至少对我来说不是。这个问题更多的是关于代理键和自然键。

国家代码不是静态的。他们可以而且确实会改变。国家更名(如埃塞俄比亚改为厄立特里亚)。它们出现了(如南斯拉夫或苏联解体)，但已不复存在(如西德和东德)。当发生这种情况时，ISO标准代码会发生变化。

在Name Changes Since 1990: Countries, Cities, and More中有更多信息

代理键往往更好，因为当这些事件发生时，键不会更改，只有引用表中的列会更改。

因此，我更倾向于创建具有int主键的country和currency表。

也就是说，varchar键字段将使用更多的空间并具有某些性能劣势，除非您正在执行大量查询，否则这可能不是问题。

为了完整起见，您可能需要参考Database Development Mistakes Made by AppDevelopers。

詹姆斯·斯基德莫尔的链接读起来很重要。

如果您将自己限制为国家和货币代码(分别为2和3个字符)，则可以很好地声明char (2 )和char(3)列。

我猜这不是一个禁忌。如果您使用的是8位字符编码，那么您要查看的列的大小分别为smallint或mediumint。

我的答案是没有一个明确的答案。只要在你的项目中选择一种方法并保持一致即可。两者都有其优点和缺点。

@cletus对使用生成的键有一个很好的观点，但是当你遇到数据相对静态的情况时，比如国家代码，为它们引入一个生成的键似乎过于复杂了。尽管现实世界的政治，国家代码的出现和消失对于大多数业务问题来说并不是什么大问题(但如果您的数据积极关注所有190-210个国家，请遵循该建议)。

普遍使用代理键是一种很好的流行策略。但请记住，它是对使用自然键对数据库进行建模的响应。好了！打开一本15年前的数据库书。到处使用自然键肯定会让你陷入困难的境地，因为最初对问题域的理解被证明是错误的。您确实希望在建模实践中保持一致性，但对于明显不同的情况使用不同的技术是可以的。

我怀疑大多数现代数据库在var(2)外键上的性能将与int字段相同(或更好)。多年来，数据库一直支持文本外键。

鉴于我们没有关于该项目的其他信息，如果您更喜欢使用国家代码作为外键，并且您可以选择这样做，我会说这是可以的。它将更容易地处理数据。这与当前的实践有点不同，但是--在这种情况下--它不会让您陷入困境。