状态定义
这里其实主要对于数据库的状态字段定义, 基本上有以下几种定义:
is_del(1|0):bit(1)或者tinyint(1)方式做的是|否类似bool处理delete_time(0|timestmap): 删除时间, 如果为0代表没删除, 非0代表删除时间state(0|number):unsigned的状态值支持多种状态递增变化
数据库表状态字段这几种方式各有各的好处, 但是这里首先不推荐 is_xxx 方式定义字段.
之所以不推荐是因为首先 is_xxx 这种定义单个状态作用太小且占用表字段列空间;
比如今天运营需要 is_del, 明天需要 is_check(审核删除), 后天需要 is_lock(锁定操作) 等字段,
这里字段随着业务不断扩展出来会导致表结构需要不停更改不断去 ADD Column.
在数据业务量少的情况每次变动的时候可能没什么, 但是后续单表数据量膨胀的时候需要追加动到表结构字段的情况就很恐怖.
并且对于 is_xxx 这种字段其实还有个问题就是 Kotlin 引入 JPA 的时候会出现解析错误,
需要自定义处理 @Column(name = "is_del") 重命名实体类字段名并让其不要以 is 开头的作为实体字段.
关于
kotlin的is_开头字段就是被坑过, 所以后续默认不采用这种方式
而 delete_time 其实主要问题就是状态类型单一已被定义成 delete, 只能表示单种状态处理没办法处理后续多种状态,
所以推荐的方式其实采用 state 单个字段处理:
CREATE TABLE `test_1`
(
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID',
`state` TINYINT(3) UNSIGNED NOT NULL DEFAULT '0' COMMENT '状态码, 采用 TINYINT3 方便后续扩展',
PRIMARY KEY (`id`) USING BTREE
)
COMMENT ='测试表1'
COLLATE = 'utf8mb4_unicode_ci'
UNSIGNED TINYINT(3) 取值 0~255 基本上已经足够日常使用, 一般状态数据不会超过这么大的值且占用也不用那么高.
后续单数据扩展状态值就行了, 由外部来定义状态列表就行了, 这样以后多更新几种状态无需动到数据库结构.