조회 시 하나의 SQL로 처리 VS 여러 개의 SQL로 처리

Question

Bid&#64;Entity &#64;Getter &#64;NoArgsConstructor(access &#61; AccessLevel.PROTECTED) &#64;ToString public class Bid { &#64;Id &#64;GeneratedValue(strategy &#61; GenerationType.IDENTITY) private Long id; &#64;Column(name &#61; &#34;member_id&#34;, nullable &#61; false) private Long memberId; &#64;Column(name &#61; &#34;product_id&#34;, nullable &#61; false) private Long productId; &#64;Column(name &#61; &#34;uuid&#34;, nullable &#61; false) private String uuid; &#64;Column(name &#61; &#34;amount&#34;, nullable &#61; false) &#64;Convert(converter &#61; MoneyConverter.class) private Money amount; &#64;Column(name &#61; &#34;status&#34;, nullable &#61; false) &#64;Enumerated(EnumType.STRING) private BidStatus status; }Product&#64;Entity &#64;Getter &#64;NoArgsConstructor(access &#61; AccessLevel.PROTECTED) &#64;ToString public class Product { &#64;Id &#64;GeneratedValue(strategy &#61; GenerationType.IDENTITY) private Long id; &#64;Embedded private Description description; &#64;Convert(converter &#61; ExpiredDatetimeConverter.class) &#64;Column(name &#61; &#34;expired_date_time&#34;, nullable &#61; false) private ExpiredDatetime expiredDatetime; &#64;Convert(converter &#61; PhotoConverter.class) private Photo mainPhoto; &#64;Convert(converter &#61; MoneyConverter.class) &#64;Column(name &#61; &#34;minPrice&#34;, nullable &#61; false) private Money minPrice; &#64;Column(name &#61; &#34;member_id&#34;, nullable &#61; false) private Long memberId; &#64;Column(name &#61; &#34;status&#34;, nullable &#61; false) &#64;Enumerated(EnumType.STRING) private ProductStatus status; }상품(Product)와 입찰(Bid)는 1:N 관계입니다.상품 상세 조회 API를 개발하려는데 상품에 대한 정보 &#43; 입찰 횟수, 평균 입찰가 를 제공해주려 합니다.이렇게 하나의 조회 대상에 연관된 테이블의 컬럼들도 가져와야 할 때 일반적으로 JOIN 이나 서브쿼리를 활용하여 1개의 SQL로 처리하는지, 여러 개로 나눠서 처리하는지 궁금합니다!

휘뚜루마뚜루루 · Answer

저도 요즘 jpa공부중인데 이런경우 그냥@OneToMany으로 join해서 처리하지 않나요?

감독님테스트가하고싶어요 · Answer

경우에 따라 다르지만 여러개 보냅니다 기껏해야 쿼리 2~3개 더 나가는거라

antop · Answer

Product Entity가 얼마나 많이 조회되는지에 따라 다르게 하겠지만조회성능이 중요하지 않다. (관리자 같은데서 현업이 가끔 본다....)@OneToMany 사용하고 product.countBid() / product.averageBidAmount()Lazy Loading을 이용하여 필요할때만 Bid를 불러오도록 한다.Product 테이블이 빈번하게 조회된다.@OneToMany 연결 끊고 Product 테이블에 입찰회수, 평균입찰가 컬럼을 만들어서 입찰이 들어왔을 때 재 집계를 해서 업데이트 한다. 장점 : Product 테이블 조회할 때 Bid 조회 안해도 됨단점 : 동시성 이슈 해결해야 함조회 전용 Product 테이블을 만들어서 Product + Bid 집계와 싱크를 맞춤 (CQRS)장점 : 조회용 Product 테이블만 SELECT하면 됨단점 : 동시성과 싱크 맞추기

wharup · Answer

코드 구조를 어떻게 생각하냐에 따라 선택이 다를텐데요모듈화를 추구한다면 보여주신 상품이랑 입찰은 별도로 다루는 게 맞습니다.상품은 상품을 등록하고 정보를 수정하는 유즈케이스가 있고입찰은 입찰을 공고하고 실시하는등의 유즈케이스가 있으므로각각의 업무 로직이 적지 않을 것 같습니다.그래서 각 업무 로직을 담고 있는 상품Service, 입찰Service 등을 만들어각 Service끼리 호출하는 게 일반적입니다만약에 하나가 다른 엔티티의 부가 속성 정도로 작다면 한 번에 조회할 수도 있겠지요.

장독깨기 · Answer

입찰횟수, 평균 입찰가니, 한 번에 가져오는게 편하겠네요.

조회 시 하나의 SQL로 처리 VS 여러 개의 SQL로 처리

5개의 답변

기술 목록