最近合作搞项目,发现了很多问题。特别的,数据库层面上的问题更为致命。记录一下,希望后面看到博客的同学们注意。
注意:以下观点只用于一般情况下的单体、微服务,不保证适用所有场景。
一、ID问题
ID名称问题
如下图:有的同学喜欢,xx_id,这就很让人迷惑。因为,一般我们使用逻辑外键的时候才会这么写,而实际开发的时候,表的id,就固定为id字段,如图二。
ID自增长、映射类型
默认id自增长、映射为JAVA种的Integer
逻辑外键
- 一张表的逻辑外键最好限制为一个,过多的逻辑外键,尽量额外建表维护。
二、字符
长度
- 最好使用四种默认长度64、255、1024、2048,使用别的长度,要有明确的要求。
- 超过2048麻烦额外建表。
适用范围
- 尽量不要用字符存枚举、类型、状态、ID
三、时间
- 不知道选的,默认选DATATIME
- 语句-默认当前时间: DEFAULT CURRENT_TIMESTAMP
- 语句-更新字段后更新时间:ON UPDATE CURRENT_TIMESTAMP
- 没有必要,不要存时间戳
四、整型
- 枚举字段使用默认:tinyint
- 不知道的整型默认:int
- 不要设定初始默认值,让应用去控制
五、字段
- 超过2048字符长度的,尽量使用额外一张表
- 如果有大字符、大内容需要存,使用文件服务。
- 如果不想建文件服务,就存文件名,然后用本地文件系统。一定不要存文件到数据库。
- 不要存模糊的字段,不要使用默认值(时间除外),因为后期会变成一个坑。
- 不要设计备注、冗余字段,要改的表,让它改,冗余设计和bug一样恐怖
六、数据库的三大范式
如果谁设计的数据库不满足的,让它改!!!
不满足范式的设计,后期大概率要出问题。
七、关系
表间关系
- 一对多、多对一的情况,可以使用逻辑外键
- 多对多的情况,一定要建中间表,而且命名要有明显的辨识度例如:tm_user_role。tm就是中间表
- 优先使用分组表,而不是分组字段。
行关系
设计二叉树行时,例如:每个行都有id、parent_id,其中parent_id是id的逻辑外键。
- 保证数据总量的有穷性、最大值不会影响性能。
- 可以的话,设计类似:00112233一样的字段作为code或字段level,进行快速识别。例如(第1-2、3-4、5-6行)、level代表树的高度。
- 不要使用二叉树分组,新建一个分组表。
八、字段切割
- 一张表最多20个字段,超过需要切割。
- 实际上最多15个就够了,超过12个字段,就应该仔细看是不是有问题。
最后,以上就是我的个人经验,如有想法,请留言,感谢。