1 、int (2 ）还是很大，MySQL 中 int 后面的只影响显示，用 tinyint 更好； 2 、1->2->3 和 1->8->5 只是你理解的顺序不一样，对于程序没什么区别；比如一个审核流程，正常可以 1->2->->3->4->5 ；但是走到 3 是不是可以驳回到 1 ，或者是不是可以跳过 4 到 5 ，或者 3 之后 4 和 5 可以同时审核 3 、不要用枚举！不要用枚举！！ ENUM IS EVIL!!!

@b821025551b 用枚举有什么问题？

直接用英文字符串，看见 state 就知道啥状态，不用在脑子里维护一个 map ，也不用代码里整注释。

@icemanpro #11 https://i.imgur.com/Iy0taMy.png 因为 MySQL 的枚举比我这个表情还滑稽

增加一个 7 备货中，很奇怪的样子。 // 不要有代码洁癖。。保持文档更新即可。。

@icemanpro 严格模式下无法插入新的条目，想新增需要 alter table ；弱类型语言（这里特指 PHP ）以及或者菜鸡一个不注意搞混了 insert xxx values(1) 还是 values('1')就炸了；与其它数据库对接不兼容，说到这里这里还有个不建议的是 UNSIGNED 属性（当然只用 mysql 的话倒是个 feature ，比如用 int 型可以直接存 ipv4 ）以及一大堆问题随便搜搜就能看见

数值类型只有作为基数（表示数量多少）和序数（表示先后顺序）使用时才有大小的语义。作为枚举类型的值，没有大小语义。 你可能以为，一个业务流程状态是序数，因为你很清楚流程是一路流转下来的。但实际上的流程，中间可能有分支、回转、跳跃。比如因为有特殊要求中途补付一些钱，比如物流弄丢了重新发货。这里每个节点使用的数字，只是为了把这个节点和其它的区别开，并没有任何大小的意义，所谓的 1 与 2 之间，只是莫某个节点与另一个节点之间，1 不是 1 ，2 也不是 2 。 换个角度想，如果用文字类型来描述，难不成能你也要让业务流程中的每个状态的名字恰好是按字典顺序从小到大？为什么用数值类型你就要有这种追求呢？

至于 eunm 会不会更快，当然是不会。类型系统的完备性，不是为了性能，而是为了有更严谨的数据一致性约束。也就是减少程序的 bug 。但有些人认为这是多余的负担。

直接用字符串

@go522000 他这个就是最佳最标准案啊，除了他说的，还有更重要的是，任何业务逻辑场景都分为住流程和细节，细节会随着业务流程变迁，但是主流成一般在一开始就可以确定，所以百位一般会进一步用来区分主流程节点，十位区分二级节点，就算一开始无法完全确定有几部主节点，但是大概分几部还是可以确定的，那么应该把 0 到 9 整体规划到几个大步骤去，而不是直接连续，这样就算主步骤一开始没有设计全也可以再加，其设计过程也是业务流程分析过程，既表达清楚又逻辑清晰，业务流程迁移方便也兼容性好，而且查询和逻辑规划也更容易