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

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

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 国际许可协议 进行许可。转载请注明出处!

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章