adoal

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

数值类型只有作为基数（表示数量多少）和序数（表示先后顺序）使用时才有大小的语义。作为枚举类型的值，没有大小语义。

你可能以为，一个业务流程状态是序数，因为你很清楚流程是一路流转下来的。但实际上的流程，中间可能有分支、回转、跳跃。比如因为有特殊要求中途补付一些钱，比如物流弄丢了重新发货。这里每个节点使用的数字，只是为了把这个节点和其它的区别开，并没有任何大小的意义，所谓的 1 与 2 之间，只是莫某个节点与另一个节点之间，1 不是 1 ，2 也不是 2 。

换个角度想，如果用文字类型来描述，难不成能你也要让业务流程中的每个状态的名字恰好是按字典顺序从小到大？为什么用数值类型你就要有这种追求呢？

我非常讨厌一些互联网行业“毕业”后做信息化的人以及盲目追随互联网布道的原生信息化人。

@BreadBig varchar 也有 varchar 的问题。这个类型在不同数据库上的长度计算单位不一样，有的是字节，有的是字符。

连管晨辰都不敢安装

@Aluhao 如果你是做业务逻辑比较复杂的信息化类型应用，新项目可以考虑上 PG 了，体验一把在严谨的数据库上认真设计数据模型、靠数据库的约束机制来保证一致性是什么样子。反正 PG 属于那种不太熟也不会踩出怪坑来的稳妥玩意儿。

人家在特定业务领域做了多少年，早就有有醇厚香浓的屎山积累。

不需要带 GUI 的 session manager 、在纯粹的终端仿真器里敲 ssh 命令的人，可能是做开发或者不接触业务系统运维的纯 infra 技术人吧。
如果是需要做业务系统的服务器运维，当你所在单位有 x 个业务部门，每个部门有 y 个系统，每个系统有 z 个服务器的时候，乘起来的数量滚动几屏。只靠在.ssh/config 里写一堆 Host……写完谁记得写了个啥。用各种乱七八糟的业务名词，做技术的人哪记得住，就算能敲补全都不知道先输入个残缺不全的啥片段再补起，简直是春池嫣韵。这时候，有个 GUI 的 session manager ，从树形结构里一堆写好的狗屁条目里视觉匹配出技术人不擅长记忆的业务名词，感谢 Xerox PARC 发明了 GUI ！

主要是看这个话题放在什么节点下。很容易说着说着就按技术节点和按照职场节点来看的人谈不到一起了。

你在前面那贴里说，一个 EoL 了好几年的 Windows 服务器，还在用，那被利用了安全漏洞活该……要知道，很多在生产环境的服务器，操作系统 EoL 了继续用的安全风险代价是低于升级、迁移带来的不确定性代价的，甚至还有业务系统开发时遇到操作系统的特定 bug 就按这个 bug 的行为做下去的（可能是来不及等补丁，也可能是开发的人根本就没意识到是 bug ，靠猜测式编程），导致操作系统打补丁都会把业务系统打挂掉。Linux 要好得多，毕竟 SSH 的协议和组件都比较简单专注。虽然历史上也有很扯淡的漏洞，但比起 Windows 来还是放心得多，赌一把也不是不行。

更悲哀的是，这种草台板子式的信息化服务，很可能颤颤巍巍地支撑着一些国计民生服务的公共服务单位运行。甲方和乙方都觉得指不定哪天会挂掉，但不敢动。不动就不动，没爆就好。