使用mysql ENUM是一个糟糕的架构解决方案吗？

Question

对我而言，就像在应用程序代码中使用硬编码值而不是常量变量一样。但那里有不同的意见。所以我无法确定。

P.S。对于这个问题的范围，我们假设性能不是问题。

Answer 1

这取决于你想要实现的目标。如果你说的性能不是问题，那么它在很大程度上取决于你的理念，以及数据的固有可变性。如果您使用ENUM来存储一周中几天的值，以帮助人类可读性和数据的“可查询性”，那么它是完全有效的用途（并且在某些情况下，使用数字或其他方面更优越）表示）。但是，如果您使用它来存储产品所属的类别（可用类别集可能很容易改变），那么这是一个非常糟糕的解决方案。

Answer 2

ENUM非常适合您知道属于静态集的数据。

如果您正在使用Mysql 5+，则存储is almost always better具有ENUM类型的静态集中的数据，如官方MySQL参考所示。更不用说数据是可读的，并且您有额外的验证层。

如果您想知道使用ENUM是否为优化，我建议您使用PROCEDURE ANALYZE。这将为您的列推荐正确的数据类型。

Answer 3

这在很大程度上取决于实际情况，但首先是列类型的要点是精确定义哪些值是允许的，哪些不是。如果在您的问题域中，您考虑存储为ENUM值的属性是已修复，因为它不可能具有其他值，那么ENUM是一个很好的选择。这方面的一个例子是性别：ENUM('male', 'female')很棒，因为第三个性别的可能性确实非常低。

如果要存储更有可能更改的值，则可以考虑将数据模型规范化为多对一关系。

Answer 4

绝不是！它们比数字领域有几个优点：

• 它们更具可读性：UPDATE Person SET state = 2 - 2代表什么？
• 他们的范围有限：如果一个人只有10个州，为什么要允许数字值11 +？
• 它们可以像它们的数字计数器部分一样使用：UPDATE person SET state = state + 1

实际上，使用数值而不是枚举就像将常量放入源代码中一样。