DTO 직접 조회: 플랫 데이터 최적화

  • 이번엔 한 방 쿼리를 보내보자.

join

@RestController
@RequiredArgsConstructor
public class OrderApiController {

    @GetMapping("/api/v6/orders")
    public List<OrderFlatDto> ordersV6() {
        List<OrderFlatDto> flats = orderQueryRepository.findAllByDto_flat();

        return flats;
    }
}
[
  {
    "orderId": 4,
    "name": "userA",
    "orderDate": "2022-05-01T15:53:40.001454",
    "address": {
      "city": "서울",
      "street": "1",
      "zipcode": "1111"
    },
    "orderStatus": "ORDER",
    "itemName": "JPA1 BOOK",
    "orderPrice": 10000,
    "count": 1
  },
  {
    "orderId": 4,
    "name": "userA",
    "orderDate": "2022-05-01T15:53:40.001454",
    "address": {
      "city": "서울",
      "street": "1",
      "zipcode": "1111"
    },
    "orderStatus": "ORDER",
    "itemName": "JPA2 BOOK",
    "orderPrice": 20000,
    "count": 2
  },
  {
    "orderId": 11,
    "name": "userB",
    "orderDate": "2022-05-01T15:53:40.033561",
    "address": {
      "city": "진주",
      "street": "2",
      "zipcode": "2222"
    },
    "orderStatus": "ORDER",
    "itemName": "SPRING1 BOOK",
    "orderPrice": 20000,
    "count": 3
  },
  {
    "orderId": 11,
    "name": "userB",
    "orderDate": "2022-05-01T15:53:40.033561",
    "address": {
      "city": "진주",
      "street": "2",
      "zipcode": "2222"
    },
    "orderStatus": "ORDER",
    "itemName": "SPRING2 BOOK",
    "orderPrice": 40000,
    "count": 4
  }
]
  • 이렇게 모든 데이터를 join 해서 조회하면 중복 데이터를 반환한다.

  • order가 아니라 orderItem이 기준이 되면서 페이징이 불가하다.

  • 하지만 쿼리가 총 한 번만 나간다는 장점이 있다.

중복 제거

  • API 스펙을 OrderQueryDto로 맞춰야 한다면 노가다로 중복을 제거해 변환할 수 있다.

  • @EqualsAndHashCode(of = "orderId")

단점

  • 쿼리는 한 번이지만 join으로 인해 DB에서 애플리케이션에 전달하는 데이터가 중복된다.

    • 상황에 따라 V5보다 더 느릴 수도 있다.

  • 애플리케이션에서 해야 할 추가 작업이 크다.

    • 분해하는 추가 작업이 필요하다.

  • 페이징이 불가능하다.

    • 데이터가 중복되기 때문에 정확한 페이징 결과가 나오지 않는다.

    • 2개만 페이지 하면 중복 데이터 2개만 나오게 된다.

Last updated

Was this helpful?