情况描述：
有以下几张表，单据表（t_bill）、货物表（t_cargo）、原料表（t_raw_material）、配置表（t_configure），表关系如下：
一张单据对应多个货物信息，每种货物都有自己对应的原料信息，货物和原料都有属于自己的配置信息。
需求如下：
当我查询一个单据信息的时候，会展示该单据下的所有货物信息，以及货物所属原料名称和配置信息，不是单纯的对象，是需要通过DTO转换的数据，意思就是说，货物信息、原料信息、配置信息需要组装成为一个DTO。
按照常理来说，直接查询单据就可以级联查询出单据明细信息，这样做也无可厚非，但是忽略了一点，如果一张单据里面包含了成千上万的货物信息，成千上万的货物又对应的成千上万的原料，同时也对应了成千上万的配置信息，这个时候就会遇到数据量太大，导致前端请求超时问题。
最开始的解决方案：
用redis缓存货物和原料对应的配置信息，这样在查询货物和原料对应的配置信息时，可以先从redis中查询，如果有直接返回，如果没有则再去数据库查询，这样可以减少数据库的开销，提高查询速度，在一定程度上看减少前端超时的问题，但是随之而来又会有新的问题，那就是货物和原料对应的配置信息更新不及时的问题，意思就是说会存在脏数据问题，所以想到这些后续还需要更改更多代码，于是过段暂时放弃这种方式。
第二种解决方案：
在查询明细信息的时候，在代码中用HashMap的方式暂存数据，形式和redis相同，以key和value的形式在内存中保存数据，因为货物和原料中都是保存的配置信息的code，根据code拿到name，返回给前端，所以查询的时候，先会去map中找，如果存在，则直接返回name，如果不存在，再去数据库中查询，然后add进map中，这样在后续的查询中，效率会更高，当然这带来不利的因素就是内存会被增加，所以这个只是暂时的解决方案。
我写这篇文章的目的在于想告诉大家，内存的性能大于Redis缓存，Redis缓存性能大于数据库直接查询。