SQL静态数据/查找列表IDENTIFIER

Question

关于静态数据表设计。在表中显示静态数据：

• 货币（代码，名称）。行示例：美元，美元
• 国家（代码，名称）。行示例：DE，德国
• XXXObjectType（代码，名称，...其他属性）
• ...

将另一个（INTEGER）列作为主键是否有意义，以便所有外键引用都可以使用它？

可能的解决方案：

1. 使用额外的INTEGER作为PK和FK
2. 使用代码（通常为CHAR（N），其中N小）作为PK和FK
3. 仅在小于一定尺寸的情况下使用代码...尺码大小？
4. 其他_______

你的建议是什么？为什么呢？

我通常使用INT IDENTITY列，但通常使用短代码足以在UI上向用户显示，在这种情况下，查询将少一个JOIN。

Answer 1

这里绝对不需要INT IDENTITY。使用2位或3位数字助记符代替。如果您的实体没有小的唯一属性，则应考虑使用合成密钥。但货币代码和国家代码不是时候做的。

我曾经在一个系统上工作，其中有人实际上有一个年表，每年都有一个YearID。并且，确实形成，2001年是第3年，2000年是第4年。它使系统中的其他所有所以更难以理解和查询，而且它一无所获。

Answer 2

如果使用ID INT或CHAR，则在两种情况下都会保留参照完整性 INT长度为4个字节，因此它的大小与CHAR（4）相同;如果你使用CHAR（x），其中x <4，你的CHAR密钥将短于INT密钥;如果你使用CHAR（x），其中x> 4，你的CHAR密钥将大于INT密钥;对于短键，通常使用VARCHAR是有意义的，因为后者具有2字节的开销。无论如何，当谈论具有 - 例如 - 500条记录的表时，CHAR（5）相对于INT密钥的总开销将仅为500字节，这对于数据库而言是有趣的，其中一些表可能具有数百万条记录。 考虑到国家和货币（例如）的数量有限（最多几百个），使用ID INT而不是CHAR（4）时，你没有真正的收益;此外，最终用户可以更容易地记住CHAR（4）密钥，并且在必须调试/测试Sql和/或数据时可以减轻您的生活。
因此，虽然我通常在我的大多数桌子上使用ID INT密钥，但在某些情况下我选择使用由CHAR构成的PK / FK：国家，语言，货币都属于这些情况。