地产广告设计网站wordpress搜索图标
最近合作搞项目，发现了很多问题。特别的，数据库层面上的问题更为致命。记录一下，希望后面看到博客的同学们注意。
注意：以下观点只用于一般情况下的单体、微服务，不保证适用所有场景。
一、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个字段，就应该仔细看是不是有问题。
最后，以上就是我的个人经验，如有想法，请留言，感谢。