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

讨论 未结 置顶 1 138
绝尘
绝尘 2018-06-13

以下内容来源<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
类名本身就要有模块前缀


个人博客地址:http://1216.top 码云/GitHub:https://gitee.com/tc608
还有不明白?追问
  • 123
    2018-07-03

    尴尬

    0 回复