和老代码相爱相杀之数据库篇

感受：刚开始没有深入进去，感觉数据库设计的很垃圾，觉得如果换成自己设计会怎样怎样，然后熟悉了一些业务和功能之后，开始试着做数据库的设计。设计过程中，根据目前的业务和功能要求，自己在向着之前的人的表设计靠拢，一些表的抽象，也是之前的人比自己设计的更好，尽管之前的人的表设计并不是那么完美，但是优秀的设计也很多，瑕不掩瑜，渐渐觉得之前人的表设计还是蛮优秀的，这一点不得不承认。

1、 数据表不加外键 ，当时看到数据表连个外键都不加，心里就对这些表很看低（觉得垃圾），后来查阅了一些资料发现，不加外键还真是有道理的，是自己学识短浅了。数据表加外键可以保证数据的一致性和完整性，我之前在有逻辑关联的数据上会加上外键，但是外键也是有缺点，在一定程度上会影响插入、删除的性能，当然不加外键，也有缺点，如果没有说明文档，不容易查看数据的外键关系，不过只要文档写得规范，这个缺点是可以克服的。

2、 实体类的划分 ，这是老代码中做的不好的地方，数据库实体类和业务实体类是混着用的，这当然和项目规范也有关系，其实之前自己写代码的时候，也没有将实体类划分清晰，我是拿数据库实体类当业务实体类使用了，当然这和我做的业务不是很复杂也有关系，查阅了《阿里巴巴Java开发手册》，我才知道实体类根据不同的数据领域原来可以划分的那么清晰，当然划分的越清晰，实体类的数量也就越多，我觉得粗略划分至少是数据库实体类和业务实体类两大类，这样虽然不及《阿里巴巴Java开发手册》中的那般详细，但是对于一般的应用也足够了。

3、 善于利用Mybatis的Criteria类 ，之前自己在项目中从来没有用到过这个查询条件类，老代码中一些地方是使用了的，简而言之这个查询类就是SQL语句中where后面的查询条件，但是这个Criteria类并不是哪里都用的，我思考了什么时候使用这个查询类比较合适，对于查询涉及的表较少，最好是一张，数据库实体类在使用Mybatis生成插件生成的时候就可以生成这个查询类，当然可以根据业务自己组装实体类，单独再写Criteria类，这样查询是把实体类的所有字段都查询出来，但可能有些字段是业务不需要的，这当然是不太推荐的。Mybatis相比于之前我们直接用JDBC写的静态SQL，它的SQL能够更加的灵活，尤其是对于查询操作来说。如果不使用Criteria类，我们想要使用多个条件查询，就直接将查询条件封装到一个类中，可以是普通的用于查询的类，也可以封装到一个Map集合中。两者的使用，我觉得应该是看具体的业务，如果是一般的列表查询的话，查询条件一般会比较简单，那么直接使用封装类会简单些，但是如果是复杂的搜索栏筛选查询，使用一个查询类封装查询条件会比较好。

本文作者：Wizey

本文链接：http://wenshixin.gitee.io/blog/2019/03/15/和老代码相爱相杀之数据库篇/

版权声明：本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！