我的要求
表需要维护状态列.
此列代表5种状态之一.
初步设计
我想我可以使它成为一个整数列,并使用数值表示状态.
0 =开始
1 =正在运行
2 =坠毁
3 =暂停
4 =停了
由于我不希望我的应用程序维护从整数到字符串描述的映射,因此我计划将它们放在单独的状态描述表中(依赖于FK关系).
然后我发现MySQL的ENUM类型完全符合我的要求.除了直接依赖MySQL之外,使用ENUM类型有任何陷阱吗?
更改ENUM中的值集需要一个ALTER TABLE
可能导致表重组的操作 - 这是一个非常昂贵的操作(如果只是在ENUM定义的末尾添加一个新值,则不会发生表重组,但如果删除一个,或改变顺序,它做一个表重组).而在查找表中更改值集就像INSERT或DELETE一样简单.
无法将其他属性与ENUM中的值相关联,例如哪些属性已停用,哪些属性有资格放入用户界面的下拉列表中.但是,查找表可以包含此类属性的其他列.
查询ENUM以获取不同值的列表非常困难,基本上要求您从中查询数据类型定义INFORMATION_SCHEMA
,并从返回的BLOB中解析列表.您可以SELECT DISTINCT status
从您的表中尝试,但只获取当前正在使用的状态值,这可能不是ENUM中的所有值.但是,如果将值保留在查找表中,则可以轻松查询,排序等.
你可以说,我不是ENUM的忠实粉丝.:-)
这同样适用于仅将列与固定值集进行比较的CHECK约束.虽然MySQL无论如何都不支持CHECK约束.
这是关于枚举的速度比较的文章.也许它提供了一些提示.恕我直言,它应限于在固定的字符串列表中使用("是/否","儿童/成人"),99%的概率在未来不会改变.
mysql中的枚举对于已经解释过的原因是不好的.
我可以添加以下事实:Enum不确保在服务器端进行任何类型的验证.如果插入一个值,该行的值不会在枚举定义中退出,则在DB中将获得nice或NULL值,具体取决于枚举字段声明的NULL-ability.
关于tinyints的观点:
- enums限制为65535个值
- 如果你不需要超过256个值,tinyint将为每一行占用更少的空间,并且它的行为更加"可预测".