一对多字典（查找）表 vs varchar vs enum？

Question

假设我们有订单表，并且订单有状态。这三个选项中哪一个最好？

1. 用于varchar状态栏
2. 用于enum状态栏
3. 使用单独的状态表，其中有status_id int和name varchar，并且在订单表中保留status_id作为外键。

哪种方法是最好的？int我怀疑使用字典表也更好，因为通过, 而不是 来搜索状态会更快varchar。

Answer 1

嗯，我是 ENUM 的拥护者——至少在有限的使用中是这样。

status我会将它与一个小的、相当静态的可能值列表一起使用。我会从unknown发现拼写错误开始。 长期以来一直在优化以在列表末尾ALTER TABLE添加新选项。ENUM

我不会用于ENUM大陆。如果有标准缩写，我会使用缩写VARCHAR。对于国家来说，我主张

country CHAR(2) CHARACTER SET ascii

使用查找表可能会降低效率。数据仓库中的“星型”模式效率可能非常低。JOINs当需要多个时会发生这种情况；ENUM避免了低效率。 VARCHAR体积庞大，这在DW应用中是一个大问题。

在许多情况下， An 的ENUM作用类似于字符串： WHERE status = 'OK'比任何一种替代方案都更具可读性。

比较两个整数与两个字符串：整数的速度还不够快，因此并不重要。

• VARCHAR-- 当体积不成问题时使用
• ENUM-- 当体积庞大成为问题并且选择数量相当小且稳定时使用。
• 字典查找——当多个表需要引用同一组内容和/或字典中有额外信息时使用。

Answer 2

MySQL 没有ENUM类型。它有一个叫做 的东西ENUM()，但它不是ENUM. 这是一个平移和一个列约束。因此，使用伪类型的维护增加了。如果用在两个地方（即桌子），

• 你现在必须维护两个地方
• 的影响JOIN是荒谬的
• 对关系完整性的影响几乎是最令人惊讶的FOREIGN KEY

如果您使用“字典表”并建立规范化关系，则可以最大限度地减少维护和复杂性。您只需在关系范例中维护这一位置，只需花费很少的额外连接成本，这会稍微慢一些。

使用 varchar 简直是愚蠢的，应该避免，恕我直言，它增加了错误的空间并且没有提供任何东西。消除单个连接几乎不值得。它还增加了表的膨胀。