一种优雅实现多表查询的新思路-51CTO.COM

哈喽，各位代码战士们，我是Jensen，一个梦想着和大家一起在代码的海洋里遨游，顺便捡起那些散落的知识点的程序员小伙伴。

上一篇文章有一些小伙伴在吐槽我的AC架构：

这里我统一补充：AC架构不是银弹，不适用于所有场景。对于需要精细化管理接口的业务，还是要拆开一个个接口去写；而对于小而美的微服务、单表CRUD比较多的管理后台，采用AC架构可以节省大量重复性编码。

也有很多小伙伴私信我：使用AC架构怎么解决联表查询问题？本文将为大家揭晓。

本文涉及技术点：存储方式、内存聚合。

一、冗余存还是范式存

在数据库设计中，冗余存储（Redundant Storage）和范式存储（Normal Form Storage）是两种不同的数据组织方式，它们各自有不同的优缺点。

冗余存储的优缺点：

优点：

查询性能：冗余存储可以通过减少连接操作来提高查询性能，因为所需数据已经被存储在了同一个地方。
减少I/O：在查询时，可以减少磁盘I/O操作，因为所有数据都在同一个表中。
简化应用逻辑：应用层不需要处理复杂的多表关联，简化了应用逻辑。

缺点：

数据不一致：冗余数据可能导致数据不一致性问题，特别是在数据更新时，需要确保所有冗余的副本都被正确更新。
存储空间：冗余存储会占用更多的存储空间，因为相同的数据在多个地方被存储。
维护困难：随着数据量的增加，冗余数据的维护变得更加困难，任何结构变更都可能涉及到多个表的修改。

范式存储的优缺点：

优点：

数据一致性：范式化减少了数据冗余，有助于保持数据一致性。
存储效率：通过消除重复数据，可以节省存储空间。
数据完整性：范式化有助于实施数据完整性约束，如实体完整性、参照完整性等。

缺点：

查询性能：范式化可能导致查询性能下降，因为需要执行多表连接来获取完整数据。
增加I/O：多表连接可能会增加磁盘I/O操作，特别是在涉及大型表的情况下。
复杂查询：应用层可能需要编写更复杂的SQL查询来处理多表关联。

我们再复习一下大学老师教过的数据库范式（Normal Forms）：

范式化是数据库设计中的一个概念，旨在减少数据冗余和提高数据完整性。有几种不同的范式，包括：

第一范式（1NF）：每个表格的每个列都是不可分割的基本数据项。
第二范式（2NF）：在1NF的基础上，所有非主属性完全依赖于主键。
第三范式（3NF）：在2NF的基础上，没有传递依赖，即非主属性只能依赖于主键，不能依赖于其他非主属性。

在实际应用中，完全遵循范式化可能会导致查询性能问题，因此通常会根据实际情况进行适度的反范式化（Denormalization），即有意引入一些冗余来优化性能。

设计数据库时，需要在数据一致性、存储效率和查询性能之间做出权衡。

二、走进“聚合”

“聚合”二字经常出现在程序员之间、程序员与产品经理的对话中，虽然产品不懂技术语言，他们只管给客户实现特定需求，为技术提供产品原型，但是技术比较关心到底是冗余存还是范式存。

如果涉及的数据需要分表存储，单表查满足不了客户需求，这时就需要进行数据聚合，传统的方式是写SQL，Join连接多张表，返回多张表的数据给前端，这种方式对数据库查询有一定的压力，整体性能虽然较好，但缺点也很明显：

随着业务量越来越大，工程里的SQL会满天飞，并且SQL会写得越来越复杂，对维护SQL的人简直是噩耗！

这意味着什么？代码写了两三年后，SQL已经很难维护了，没人敢动，每次看SQL都特别费劲，还不知道哪一天会出现慢SQL。

其实除了写SQL语句，我们还能通过仓库实现层做数据聚合，这就是所谓的“内存Join”，把数据库压力转移到了不要钱的CPU与内存中，具体方法如下：

查询参数Query对象添加Boolean fillXxx字段，用于控制是否要聚合。
仓库实现XxxRepositoryImpl实现fill(Query query, List<Model> models)方法，models就是查询出主表的结果集，通过query.fillXxx=true控制聚合其他表的数据。

这个fillXxx就是聚合参数，大多数情况下是默认关闭的，也就是默认还是单表查询，如果需要聚合，由前端传参控制，这样既可以兼顾性能，也可以兼顾功能，我们按需聚合数据即可。

下面我们看看一个真实案例，预约单仓库实现，聚合预约主体、预约记录、预约主体评价：

/**
 * 预约单仓库实现
 */
@Repository
public class AppointmentOrderRepositoryImpl extends
        BaseRepositoryImpl<AppointmentOrderMapper, AppointmentOrder, AppointmentOrderPO, AppointmentOrderQuery> implements
        AppointmentOrderRepository {


    // 聚合方法
    @Override
    public void fill(AppointmentOrderQuery query, List<AppointmentOrder> appointmentOrders) {
        Map<String, AppointmentOrder> orderId2appointment = appointmentOrders.stream().collect(Collectors.toMap(AppointmentOrder::getOrderId, o -> o));
        if (query.getFillAppointment()) {
            // 聚合预约主体
            this.fillAppointment(appointmentOrders);
        }
        if (query.getFillAppointmentRecords()) {
            // 聚合预约记录列表
            this.fillAppointmentRecords(orderId2appointment);
        }
        if (query.getFillAppointmentComment()) {
            // 聚合预约主体评论
            this.fillAppointmentComments(appointmentOrders);
        }
    }


    private void fillAppointment(List<AppointmentOrder> appointmentOrders) {
        // 通过预约单的主体ID列表（去重）查询主体
        Set<String> appointIds = appointmentOrders.stream().map(AppointmentOrder::getAppointId).collect(Collectors.toSet());
        List<Appointment> appointments = AppointmentQuery.builder().idIn(appointIds).build().list();
        if (CollKit.isEmpty(appointments)) {
            return;
        }
        // 按主体ID映射，把主体的信息写到预约单内
        Map<String, Appointment> map = appointments.stream().collect(Collectors.toMap(Appointment::getId, o -> o));
        for (AppointmentOrder appointmentOrder : appointmentOrders) {
            Appointment appointment = map.get(appointmentOrder.getAppointId());
            if (appointment != null) {
                appointmentOrder.setAppointment(appointment);
                appointmentOrder.setAppointName(appointment.getName());
            }
        }
    }


    private void fillAppointmentRecords(Map<String, AppointmentOrder> orderId2appointment) {
        // 查出指定预约单ID列表的预约记录
        List<AppointmentRecord> appointmentRecords = AppointmentRecordQuery.builder().orderIdIn(orderId2appointment.keySet()).fillTimeSchedules(true).build().list();
        if (CollKit.isEmpty(appointmentRecords)) {
            return;
        }
        // 按预约单ID分组，让预约单关联多条预约记录
        Map<String, List<AppointmentRecord>> map = appointmentRecords.stream().collect(Collectors.groupingBy(AppointmentRecord::getOrderId));
        for (String id : map.keySet()) {
            orderId2appointment.get(id).setAppointmentRecords(map.get(id));
        }
    }


    private void fillAppointmentComments(List<AppointmentOrder> appointmentOrders) {
        // 查出指定预约单ID列表的主体评论
        List<String> orderIds = appointmentOrders.stream().map(AppointmentOrder::getOrderId).collect(Collectors.toList());
        List<AppointmentComment> appointmentComments = AppointmentCommentQuery.builder().orderIdIn(orderIds).build().list();
        if (CollKit.isEmpty(appointmentComments)) {
            return;
        }
        // 按预约单ID分组，让预约单关联首条预约主体评论
        Map<String, List<AppointmentComment>> map = appointmentComments.stream().collect(Collectors.groupingBy(AppointmentComment::getOrderId));
        for (AppointmentOrder appointmentOrder : appointmentOrders) {
            appointmentOrder.setAppointmentComment(CollKit.isNotEmpty(map.get(appointmentOrder.getOrderId())) ? map.get(appointmentOrder.getOrderId()).get(0) : null);
        }
    }


}

需要注意的是，fill方法要对多条结果进行批量处理，如果是单个结果，每一条结果都需要聚合多表数据，那势必会加大内存与数据库连接的负担。以上预约单表聚合其他三张表，比SQL的Join多调了3次查询，但好在逻辑清晰，减少维护SQL的负担。

聚合查询的打开方式就很简单了，如果前端不传聚合参数，那么由后端接口来控制：

// 设置聚合参数（或由前端传入）
query.setFillAppointment(true);
query.setFillAppointmentRecords(true);
query.setFillAppointmentComment(true);
// 分页查询后，会自动调用fill方法，对结果集聚合
Page<AppointmentOrder> page = query.page();
// 调用聚合方法（以下代码在D3Boot框架内已实现，不需要写）
appointmentOrderRepository.fill(query, page.getRecords());

我们通过这种方式来灵活聚合多表数据，不仅不用改动Controller，还能兼顾多种数据聚合的场景，这种数据的聚合，不一定要聚合数据库的数据，也能聚合第三方接口的数据。仓库接口只关心需要提供什么数据即可，怎么聚合数据、数据源来自哪儿，是仓库实现要负责的事情。

三、写在最后

目前这种聚合方式也只适用于大部分场景，对于多张大表的聚合，还得考虑是用数据库Join还是内存Join的方式进行，或者在设计的时候就要考虑冗余存而不是范式存。