2022 了，现在还是用 1 ，2 ，3 数字表示状态么，还是用英文表示呢

确实有点难舍难分，我两种都用过，string 易读怕写错，tinyint 省空间查数据头大

btw ，这个和语言是不是没有关系？我写 Go 多一点

除非性能敏感，我喜欢用 string ，没必要省那一点点空间牺牲 sql 的可读性。

我也比较喜欢用 string ，最近接了个老项目，数据库全是 12345 ，关键还没有数据字典和注释，全靠猜，真尼玛头大

要查询用 int ， 否则随意

其实完全可以用个 hashmap 做封装啊

不写 Java ，但我一般会搞一个 enum ，然后数据库里就用 int 来映射。

写 java +1,我以为是规范，int 省内存太多了

新手吧，有点开发经验的人都不会问这个问题

enum

犹豫就用自己喜欢的那个，自从用了 mongo 就喜欢用枚举，数据库映射就是字符串，可读性高

我直接写中文状态+中文表头。 就是被其他 123456 项目迫害的。

tinyint

mysql 不是有 enum 类型么, 干么不用

string 了，int 只能数字，而 string 还可以包含中文，数字等，不会限制太死

数据库里 tinyint ，程序里就一个枚举类映射的事

2022 了，不用 enum 吗

我还是习惯在 Java 里定义 enum ，数据库存 tinyint

Java:enum -> MySQL:tinyint

查询性能相差并不多。但是节约的沟通和转换成本就很可观。

＃12
＃15
enum 类型每次加一种枚举的还得改一次 DDL

代码里面用枚举，数据库存英文 (⊙ˍ⊙)

用 tinyint 注释里维护 1-xx 2-xx

看情况，如果几个数字就能搞定就存 tinyint ，如果需要知道这个字典的大概含义，存 varchar 。

tinyint

java 用枚举, 数据库用字符串; 枚举->数据库 jpa 默认用枚举名称映射. 优点是看 sql 语句的时候不用查 1 2 3 4 是什么意思了, 缺点是占内存. 不过无所谓,项目对性能不敏感

改 DDL 有什么要紧的, 一句话的事, 都 mysql8 了, ddl 随便改

通过 enum 来映射吧，类里面会有相关注释的

varchar(20)，为了这点性能牺牲可读性太不值当了。

看表的预估数据量，如果数据量预估不会太大，且这张表涉及的接口等调用产生的数据量也不会很大，就存 varchar 增加可读性，代码中用枚举或者常量来存放这些状态枚举，如果数据量预估会持续增长或者肯定比较大，或者涉及到的接口、调用产生的传输数据量也比较大，存 tinyint 或者 int 减少空间占用

如果你的表有几千万的数据，并且值是稀疏的，可枚举的，使用 int 会比 varchar 要少占用很多的存储空间，量变决定质变。

用 int varchar 都有个问题，如果不小心写入了一个范围外的值，代码就无法处理了，而且用 int 的可读性也很差。

MySQL 直接支持了 enum 类型，用 MySQL 的 enum 类型在数据库层面提供了约束，不会出现范围外的值，同时 enum 的可读性也更好。
dev.mysql.com/doc/refman/8.0/en/enum.html

Java 里用枚举类映射，数据库里是 tinyint

char(1)

enum 是最优解，但是我不怎么用。我用数字多。因为项目大部分状态是 0 和 1 为主。如果超过范围，按照业务复杂程度选择数字还是 string 。

tinyint

如果状态值不多（比如只有 1 、2 个，或者不超过 5-6 个），tinyint ，结合模型字典对照得到字符串在程序中做比较和查询使用。
如果状态值在设计阶段就已经能够预估到未来存在难以维护的现象（比如 3 代表什么，5 代表什么，然后 3 被遗弃），建议 enum ，enum 的效果同上面提到的 tiny+程序内模型字段的作用一样。

反正没 varchar 什么事。

看项目规模, 如果没有千万行记录的量级, 就用 varchar 吧

用枚举+int 就好

我以前是使用数字, 现在改为了使用字符串, 然后 Java 代码中使用枚举. 原因是字符串更加直观, 一看英文就知道当前属于什么状态, 而数字还需要去看代码或文档才能知道. 有的人会说数字性能更好, 但数字比字符串好的一点点性能完全不如让数据直观实在.

varchar 一把梭 方便得很 不差那点性能

enum+varchar ，纯数据和代码可读性都更好些

枚举对应数据库的 tinyint(3)

现在是用 varchar

我怀疑这个论坛人的真实水平，可能只有菜鸡会上这个论坛吧，居然这么多人说用枚举，笑死人了

要不试试 bit

居然这么多人说牺牲这点性能值得，这边牺牲一点那边牺牲一点，真当服务器不要钱啊

代码中肯定是用 enumerate ，方便管理使用
至于映射到 MySQL 是什么反而随意了，int varchar 都不差，MySQL 中的 enum 我没用过（没听过哈哈）

我觉得代码中一定要用 enumerate 去限制，这个很重要

其实吧，我通常用 CHAR ，固定一或两个字符可以表示很多状态了，也比 INT 直观一些，2 位 CHAR 比一个 64 位 INT 占空间还少，性能的话跟 INT 也没差，应该能比 VARCHAR 好。

考虑这个问题的前提是你的业务真的有那么大量，否则那点性能差异根本不是瓶颈，所以一般情况下你觉得什么顺手用什么，看什么顺眼用什么，甚至抓阄决定都可以。

数据量百万以上 建议 int 你会回来感谢我

int+枚举

出来说说，只破不立非君子 讽而不教亦小人

先收藏，蹲答案。。。以前习惯用 1234 来表达不同的状态，后来遇到有客户流程随便改，用数字很容易混乱，现在项目习惯用 varchar 加字典来表示。

tinyint

用什么 varchar ，定长不是用 char 更合适吗

微软的蓝屏代码，本质是就是枚举。你觉得你比微软强？证明一下。

楼上说用枚举其实才是最正确的。原因是，枚举的本质，是对数据与意义，做强一致性约束。这种约束能强迫大家统一数据与规范，能提高整个系统的正确性与可靠性。当然，万事万物都有缺点，枚举的缺点是效率低，具体一点是，每次使用时，都要先查一下；如果需要创建新的状态，还要走一个申请流程，还要查一下是否重复或冲突。

无论如何都是 enum 。。。自从我好多年前知道有 enum 这样的类型后，再不会设计 int 型数据表示状态。

可读性，约束性，比一切都重要。改 ddl 再 2022 年了不要太简单。无论是流程和工具，都是非常 easy 的事。但是让我去看一个 sql 满屏幕的 xx=1 ，xx=3.。我日他先人。。。

Java 用枚举类映射->数据库里是 tinyint~也没什么不可读性的~

枚举 + varchar

说实话，当量达到一定数量的时候，改 DDL 非常头疼，一个不到 1000 万级的大表，需要停服，一个字段数据库跑 10 几分钟

tinyint ，写好注释就完事。

我们是有一个状态码表和状态码枚举类,业务表的状态根据这个来映射,字段类型用 tinyint 或 char 都可以

tinyint ，预留扩展枚举的余地

肯定是 int,tinyint 类型.
性能和存储空间更重要.可读性可以靠文档来解决,但因为用字符串造成的性能问题很难用其它办法来解决.

如果你的系统完全不在意性能,才考虑用字符串

都说 int 和 varchar 有性能差距，那么谁能说说性能差在哪？为什么会有性能差呢？

我见过 varchar 类型 1 、2 、3...😂

tinyint