数据库表设计的一些改进思路整理在此，收益很多，

以下内容来源<redkale 技术交流群>
整理下来逐一领会，感谢张老师（redkale作者）的指导

Redkale<redkale@qq.com> 8:58:13
表命名最好能让人一目了然，  除了表现出内容还要能表的数据模型
-----------
Redkale<redkale@qq.com> 9:04:07
比如我的设计习惯：
xxxrecord表示流水型的数据， 数据量会很大, 通常需要分库分表， 如：payrecord、loginrecord
xxxinfo，xxxdetail表示内容型数据， 数据量可大可小（中短期内不会分表），如：userdetail（用户表）、orderinfo（订单表）
xxxconfig 表示配置型数据，数据量有限。
-----------
Redkale<redkale@qq.com> 9:06:54
而且你的表名也体现不出所属模块来
这些设计细节其实很重要， 比文档重要得多，   只要你能做到别人看你表结构就能读懂业务逻辑就说明合格了

-----------
Redkale<redkale@qq.com> 9:08:57
你看redkale-demo、redkale-oss， 每个表名的前缀就是模块名， 这样别人看表名就知道这个表在哪个模块，被哪个Service调用
------


Redkale<redkale@qq.com> 9:11:19
状态字段最好都用smallint  也就是short
Redkale<redkale@qq.com> 9:11:59
别人一看short字段就知道是状态字段或者枚举值字段

Redkale<redkale@qq.com> 8:58:13
表命名最好能让人一目了然，  除了表现出内容还要能表的数据模型

Redkale<redkale@qq.com> 9:04:07
比如我的设计习惯：
xxxrecord表示流水型的数据， 数据量会很大, 通常需要分库分表， 如：payrecord、loginrecord
xxxinfo，xxxdetail表示内容型数据， 数据量可大可小（中短期内不会分表），如：userdetail（用户表）、orderinfo（订单表）
xxxconfig 表示配置型数据，数据量有限。

Redkale<redkale@qq.com> 9:06:54
而且你的表名也体现不出所属模块来
这些设计细节其实很重要， 比文档重要得多，   只要你能做到别人看你表结构就能读懂业务逻辑就说明合格了
绝尘(237809796) 9:07:46
好，从表结构  表名开始再加强升级
绝尘(237809796) 9:08:50
最好能不用文档，每个人都能看懂入门redkale
Redkale<redkale@qq.com> 9:08:57
你看redkale-demo、redkale-oss， 每个表名的前缀就是模块名， 这样别人看表名就知道这个表在哪个模块，被哪个Service调用
绝尘(237809796) 9:09:50
嗯
Redkale<redkale@qq.com> 9:11:19
状态字段最好都用smallint  也就是short
Redkale<redkale@qq.com> 9:11:59
别人一看short字段就知道是状态字段或者枚举值字段
绝尘(237809796) 9:13:03
@Redkale 好，认真改善
绝尘(237809796) 9:13:19 
Redkale<redkale@qq.com> 9:13:37
还有主键，  一个表里最重要的就是主键字段， 应该注释更详细点
Redkale<redkale@qq.com> 9:13:51
 

Redkale<redkale@qq.com> 9:15:38
这样以后如果要分库分表，  别人一看注释就知道这个表的数据能按什么维度分表
Redkale<redkale@qq.com> 9:16:10
比如这个回合表， 就只能按日期时间、userid、nodeid分表， 不能分其他维度了

Redkale<redkale@qq.com> 9:17:32
这样新人上手成本很低，  只要将一遍所以的设计规范就知道了， 不用每个功能对着数据表、代码看， 而且每个人的风格不一样， 看起来更头大

Redkale<redkale@qq.com> 9:19:19
你的`createTime`， 一会 bigint、一会date 一会 timestamp 
Redkale<redkale@qq.com> 9:20:58
状态字段禁止使用0表示由意义的值
Redkale<redkale@qq.com> 9:21:12
你这样过滤查询会很蛋疼
Redkale<redkale@qq.com> 9:21:35
传0，redkale会认为不过滤
绝尘(237809796) 9:21:49
确实有这个痛点
文(1101001213) 9:22:25
0一般都是初始值  
Redkale<redkale@qq.com> 9:22:27
你是不是觉得存0比存1少占硬盘空间  
追梦(40839292) 9:22:29
对于枚举，状态等，通常0保留
绝尘(237809796) 9:22:29
从1开始，这样就解决了吧
绝尘(237809796) 9:22:46
@Redkale 一样的吧
IT小萌新(373038132) 9:22:56
主要是int的初始值是0
立立✌️(853089986) 9:23:09
你们在做什么项目啊
文(1101001213) 9:23:14

Redkale<redkale@qq.com> 9:23:37
用short， 有3万多，  你就不能大方点， 用 10 20， 非要1/2    
IT小萌新(373038132) 9:23:37
不过老大设计表的时候确实很讲究
IT小萌新(373038132) 9:23:39
厉害
文(1101001213) 9:23:54
我喜欢
文(1101001213) 9:23:57
10 20
Redkale<redkale@qq.com> 9:24:24
用10 20 ，这样中间还可以穿插意义相近的状态
文(1101001213) 9:24:26
因为动不动业务变更   才好往里面加
追梦(40839292) 9:24:39
群主一看，就是带头做过项目的
绝尘(237809796) 9:24:46
有个地方我也用上10 20了
文(1101001213) 9:24:58
跟分配菜单排序一样的道理
IT小萌新(373038132) 9:25:33
嗯 受教了
绝尘(237809796) 9:26:10
群主是干 CTO的，才赖得带项目呢
Redkale<redkale@qq.com> 9:26:19
比如你设计 1：正常、2：删除；   以后业务发展，加其他几个状态。 3：审批、4冻结   你看这值顺序不觉得别扭了
用10, 20.      10:正常； 20：删除；   以后加： 12：审批； 14：冻结， 这样后续还可以再扩展
文(1101001213) 9:26:58
对的   
绝尘(237809796) 9:27:00
嗯，信息量好大，得好好吸收
绝尘(237809796) 9:27:24
回头一一改进
追梦(40839292) 9:27:27
马屁拍的响@绝尘 
文(1101001213) 9:27:30
但是要是用上流程引擎的话  就是另一回事

追梦(40839292) 9:27:47
群主受用的啊

Redkale<redkale@qq.com> 9:28:56
用户没输入的信息最好都为空，  你默认为男，  以后数据分析， 你根本不知道用户是真的设置为男，还是系统默认赋值的
绝尘(237809796) 9:29:18
我是发自内心的好不好，@追梦 
IT小萌新(373038132) 9:29:49
群主思维很缜密
绝尘(237809796) 9:29:51
对
IT小萌新(373038132) 9:29:58
不愧是数学常年满分的
中国-虾米(1462996820) 9:30:05
布尔的 列 为啥不用 true/false。
文(1101001213) 9:30:07
空的话 null建议不要
Redkale<redkale@qq.com> 9:30:49
除了text、blob， 其他常规字段都不能为null， 特别是number字段
绝尘(237809796) 9:30:52
@中国-虾米 布亇只有两个值
追梦(40839292) 9:30:56
嗯，不要用null，处理起来麻烦
绝尘(237809796) 9:31:09
扩展就废了
Redkale<redkale@qq.com> 9:31:20
我的表结构里没有boolean类型， 都是short
中国-虾米(1462996820) 9:31:40
只能是 0和1
文(1101001213) 9:31:41
特别是 统计查询 还有数据分析时  null的时候 你会发现好烦
中国-虾米(1462996820) 9:31:50
要是 short 还可以其他
中国-虾米(1462996820) 9:32:01
为啥 不用 bit


Redkale<redkale@qq.com> 9:32:14
如果是可叠加的状态值， 最好设计成1/2/4/8/16 这样 位运算可以叠加
文(1101001213) 9:33:26
get了
Redkale<redkale@qq.com> 9:34:26
以前有些表字段，  isHide、isDel、isRead， 看着都急死
文(1101001213) 9:34:54
条件太多 有时自己都乱
Redkale<redkale@qq.com> 9:35:12
初级感扑面而来
绝尘(237809796) 9:35:16
感觉被扒光了，站在大街，但这些都是老大青春换来的经验，值得认真思考和学习  
绝尘(237809796) 9:35:30
很爽

Redkale<redkale@qq.com> 9:35:42
还没看你代码呢  
追梦(40839292) 9:35:43
群主，现在在干嘛？
龙飞在天(121156) 9:35:51
@Redkale 老大，为啥不建议用tinyint呢？
文(1101001213) 9:36:20
他在给他分析  数据库设计  代码规范@追梦 @绝尘 

Redkale<redkale@qq.com> 9:37:35
tinyint 对应  byte，   现在什么年代了， 还计较1个字节和2个字节的差距吗， 统一short最简单

Redkale<redkale@qq.com> 9:38:57
现在数据库很多类型我都忘了，  只需要知道常见的类型就够用了
mysql8 没到生产环境的量 也不知道性能好在哪些地方
Redkale<redkale@qq.com> 9:41:48
装过mysql8， 又还原5.7了， jdbc驱动变动太大了

Redkale<redkale@qq.com> 9:44:16
然后呢， 你很需要这个特性吗

Redkale<redkale@qq.com> 9:45:38
目前没碰到常规关系型数据库设计搞不定的数据类型
Redkale<redkale@qq.com> 9:50:24
做后台要多花时间思考表设计， 这个层面是很少变化的，  如果用大量时间在花哨的API层面，过两年不流行了就得跟着新框架屁股后面跑

Redkale<redkale@qq.com> 9:52:15
特别是通才后台开发者， 表、代码、页面都一个人做。    如果是专长的另当别论

Redkale<redkale@qq.com> 10:03:07
表名和类名是一样的吗

表名通常与业务领域模型一致
Redkale<redkale@qq.com> 10:08:01
类名本身就要有模块前缀

博客地址：https://1216.top 码云/GitHub:https://gitee.com/tc608