新催收系统数据库表设计的小结

总结下前几个月设计的新催收系统，主要是数据库方面的一个设计。

解决旧催收系统的一个严重的性能问题。

可以讲需要开发新催收系统的根本原因，就是这个。

 

主因只有一个，就是帐单表h_bills。

这个表包括整个系统平台的所有帐单，连不需要催收的帐单和爷爷辈的帐单都存在里面。

当时查了下，整个帐单表大概有大几百万条的帐单记录。

 

让情况更糟糕的是新上的产品中有了存在多期帐单的分期产品。根据业务的需求就需要把标所有需要催收的帐单进行一个合并显示，不然按原来的显示逻辑就不准确了，也会造成多个催收人员同催一个标的情况出现。

 

查询待催收列表还需要连接其它几个大表。

这样这个查询列表的sql就变成：

大几百万的帐单数据 一堆表连接 查询 分组

一个sql下来大几十秒的节奏，还只是在数据库执行结果。

 

于是重构催收系统就提上了日程，开了技术评审会。

会后DBA组大佬向我们讲了他的解决方案，冷热分离。

只把我们需要使用的帐单记录，每天更新。这样就可以解决帐单表数据过大的问题。

这启发了我们。

 

我们经过几天的思考与讨论得出：新催收系统数据库设计的大体。

主要就是h_bills表，问题都在这，可以讲只要这个解决了，相关的表就如同吃饭喝水般简单。

1. 根据我们的业务逻辑（同一个标，同一时间，只有一个催收人员进行催收），可以把我们原来的帐单表转成一个新表案件表h_cases，一个案件记录可以代表一个标，多个帐单。这样就可以预先处理好数据，避免查询时group by。
2. 只把催收需要的数据导过来，减少查询时数据量。
3. 字段冗余，把相关连的表字段，查询展示用到的常用字段放到h_cases，避免了表连接。

 

根据这几点改进后，想想就觉得查询速度很快。

新催收系统也确实是列表响应速度非常快。

但新系统后来因为新组长的到来我并没有参加多少，但是数据库设计大体是和之前我们设计的是一样的，具体有哪变动就不知道。

有时，我在想如果没有我们之前设计出的数据库方案，新来的人会怎么设计，会不会有不一样的设计。

或者说新来的人的新催收系统开发之路会不会变得道路坎坷，因为他们毕竟不了解业务需求，虽说新组长是原来公司的技术部催收组组长。