一.数据库 id 问题
1.业务 id 是否有连续的需求
2.业务 id 使用数据库自增是否合理
3. id 是否需要展示给客户
4.id 是否需有需求推断时间等信息
根据 id 的后期需求,采用自定义 id 或 数据库自增 id 或 两者结合
二、数据库表结构设计
1.设计表结构必须从长远的业务考虑,否则容易导致后期改表,工作量剧增
2.设计表尽量要考虑业务关联性,如消息存储,是否有必要关联删除
3. 数据删除是否采用假删除,即业务删除
三、命名
合理的命名一定会提高项目的可读性,复用性,容易后期更改
1.类命名要根据业务核心定义,需见名知意
2.枚举命名,枚举一般是表中某个业务字段唯一的时候使用,需要明确表面+字段
四、注释
合理的注释合理有效的增加可读性
1.注解尽量详细描述功能
五、接口定义
定义接口必需要考虑复用,而不是每个需求定义一个接口
如一个用户表
- 根据用户id 查询用户名称,定义一个接口
- 根据用户id 查询用户手机号,定义一个接口
- ...
上述是反例,开发一个根据用户 id 查询用户所有信息的接口是非常必要的
对特定表的接口需要写在特定表的 mapper 里,尽量不要在别的 mapper 里写其他接口
六、索引设置
大部分索引都是用于查询优化,实际中,表中业务数据如果是唯一的,则必需设置唯一索引
不能完全将数据的唯一性通过业务控制,完全可能会产生脏数据,导致系统奔溃
七、数据的生命周期
- 要考虑增加到系统的数据,什么是否有必要清除
- 是否需要关联清除
持续更新总结中 。。。