阿里开发规范禁止超过三张表 join,我们如何规避?

超过三张表的 JOIN 是否合适取决于具体的场景和需求。这里有几个方面可以考虑:

合适的场景

  1. 数据量小:如果参与 JOIN 的表数据量较小,且查询相对简单,那么即使是多表 JOIN 也不会带来明显的性能问题。
  2. 必须的业务需求:某些业务需求可能要求在一个查询中获取多张表的数据,这种情况下,多表 JOIN 是必要的。
  3. 数据库设计和优化:数据库的设计和索引优化良好,可以有效提高多表 JOIN 的性能。

不合适的场景

  1. 数据量大:当表的数据量很大时,多表 JOIN 可能导致查询速度变慢,影响系统性能。
  2. 复杂查询:多表 JOIN 会导致查询语句复杂,增加理解和维护的难度。
  3. 频繁查询:如果频繁进行多表 JOIN 操作,可能会导致数据库负载过重,影响其他操作。

优化策略

如果确实需要进行多表 JOIN,可以考虑以下优化策略:

  1. 索引优化:确保参与 JOIN 的列有适当的索引,以提高查询性能。
  2. 拆分查询:将一个复杂的多表 JOIN 查询拆分成多个简单的查询,然后在应用程序代码中合并结果。
  3. 使用视图:在数据库中创建视图,将复杂的多表 JOIN 封装在视图中,简化查询。
  4. 缓存:使用缓存机制存储频繁查询的结果,减少数据库查询的频率。
  5. 建表的时候做冗余设计:这样可能不符合数据库设计的范式,但实际开发中经常会这么操作。

实际应用中的示例(拆分查询)

在电子商务系统中,可能会遇到以下几种情况:

  1. 客户订单查询:需要查询客户的订单及其订单项和对应的产品信息。在这种情况下,超过三张表的 JOIN 是合理的,但需要注意性能优化。
  2. 统计分析:需要对多个表进行统计分析,此时可以考虑使用数据仓库或 OLAP(在线分析处理)系统来进行复杂查询,减少对事务性数据库的影响。

具体实现示例

假设我们在一个电子商务系统中,有 Orders、Customers、Products 和 OrderItems 四张表。我们需要查询某个客户的订单及其订单项和对应的产品信息。

// OrdersMapper
@Mapper
public interface OrdersMapper {
    @Select("SELECT * FROM Orders WHERE customer_id = #{customerId}")
    List<Order> selectByCustomerId(Long customerId);
}

// OrderItemsMapper
@Mapper
public interface OrderItemsMapper {
    @Select("SELECT * FROM OrderItems WHERE order_id = #{orderId}")
    List<OrderItem> selectByOrderId(Long orderId);
}

// ProductsMapper
@Mapper
public interface ProductsMapper {
    @Select("SELECT * FROM Products WHERE product_id = #{productId}")
    Product selectById(Long productId);
}

// CustomersMapper
@Mapper
public interface CustomersMapper {
    @Select("SELECT * FROM Customers WHERE customer_id = #{customerId}")
    Customer selectById(Long customerId);
}

// OrderService
@Service
public class OrderService {

    @Autowired
    private OrdersMapper ordersMapper;

    @Autowired
    private OrderItemsMapper orderItemsMapper;

    @Autowired
    private ProductsMapper productsMapper;

    @Autowired
    private CustomersMapper customersMapper;

    public List<OrderDTO> getOrdersByCustomerId(Long customerId) {
        List<OrderDTO> result = new ArrayList<>();
        List<Order> orders = ordersMapper.selectByCustomerId(customerId);
        Customer customer = customersMapper.selectById(customerId);

        for (Order order : orders) {
            OrderDTO orderDTO = new OrderDTO();
            orderDTO.setOrderId(order.getOrderId());
            orderDTO.setOrderDate(order.getOrderDate());
            orderDTO.setCustomerName(customer.getName());

            List<OrderItem> orderItems = orderItemsMapper.selectByOrderId(order.getOrderId());
            List<OrderItemDTO> orderItemDTOList = new ArrayList<>();

            for (OrderItem orderItem : orderItems) {
                Product product = productsMapper.selectById(orderItem.getProductId());

                OrderItemDTO orderItemDTO = new OrderItemDTO();
                orderItemDTO.setOrderItemId(orderItem.getOrderItemId());
                orderItemDTO.setProductName(product.getProductName());
                orderItemDTO.setQuantity(orderItem.getQuantity());
                orderItemDTO.setPrice(product.getPrice());

                orderItemDTOList.add(orderItemDTO);
            }

            orderDTO.setOrderItems(orderItemDTOList);
            result.add(orderDTO);
        }
        return result;
    }
}

// OrderController
@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @Autowired
    private OrderService orderService;

    @GetMapping("/customer/{customerId}")
    public List<OrderDTO> getOrdersByCustomerId(@PathVariable Long customerId) {
        return orderService.getOrdersByCustomerId(customerId);
    }
}

通过这种方式,我们可以实现多表查询,同时注意查询的性能和复杂性。具体应用中需要根据业务需求和系统性能做出权衡和优化。

  • 6
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

编写美好前程

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值