创建一个“Id”列是否值得？

Question

我有一个表，它有一个 column Name，它的类型是VARCHAR2(20)唯一的，不能为空，也不能更改。

起初我将它用作该表的主键，但我想知道创建另一列Id（当然使用更合适的命名）并处理与它的表关系是否更好。

我知道拥有一Id列是一种常见的最佳实践，但我听说Id应该避免将数据库与大量无意义的列聚集在一起（一Name列附加了更多的语义）。

在这种情况下，您有什么建议？

Answer 1

由于名称是唯一的并且永远不会改变，因此从关系理论的角度来看，它肯定是一个很好的候选键。

您可能会发现出于空间和性能原因，使用整数代理键更可取，因为它比每个表中具有该表的外键的文本占用的空间更少（并且每个索引，因为 FK 通常是索引列）。在整数列上搜索/加入的操作也会更快，但对于加入此表并需要输出和/或按名称排序的查询，您可能会发现从 id 到 name 的额外工作会消除一些好处。当然，空间和性能差异可能不足以对您的项目产生影响，此时这归结为偏好。

事实上，我怀疑即使使用 UUID 也可能比使用名称更快，假设您的 DBMS 具有正确的 UUID 类型，因此它们以紧凑的二进制形式存储而不是作为文本字段，尽管该类型的固定 16 字节长度可能比平均长度更长名称值的长度，因为与固定长度二进制值的比较比可变长度字符串之间的比较要快（对此进行基准测试并查看差异是否确实很重要）-尽管除非您有理由使用 UUID（复制问题或诸如此类）较小的整数类型当然会更有效并占用四分之一的空间。

tl;dr：所描述的 name 列是一个非常好的候选键，实际上理论上是完美的，但在实践中，整数代理键会占用更多空间，处理效率更高。