• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

안녕하세요 질문이있습니다.

20.11.05 21:38 작성 조회수 243

0

안녕하세요 김영한님

다름이 아니라 jpa 사용하면서 생긴 궁금증때문에 글을 남겨봅니다.

현재 Order를 추가로 생성하기 위해 API 에서 memberId, itemId를 받아와서

Member 조회 (select 1번)

Item 조회 (select 1번)

Order에 Set 후 추가 (insert 1번)

이런 식으로 되는 것 같은데요.

이렇게 insert 1번을 위해 select를 2번 날리는 방법이 일반적인 방법인가요?

테이블이 복잡하고 외래키 관계가 많아지면 사전 select가 3~4번 이상도 나갈 수 있을 것 같은데

이럴땐 일반 날쿼리를 써야하나 고민이 됩니다.

실무에서는 그냥 감수하고 select 날려서 쓰는지 궁금합니다.

한가지 질문이 더 있습니다.

만약 게시판에 댓글을 추가할 때

board.getComments.add(comment);

이런식으로 insert 한다고 치면

이것도 결국 불필요한 select가 나가야 하고 (LazyLoading 발동하면)

혹여나 그 select의 결과가 수백 수천개라면 (댓글이 수백 수천) 문제가 될 것 같고

사실 많은 경우는 자식 엔티티 갯수가 적다는게 보장되지 않는 경우일텐데

일반적으로 저렇게 add 하는 경우가 실무에서 잦은가요?

아니면 대부분은 그냥 comment.setBoard(board)해서 넣는 방식인가요?

감사합니다.

답변 2

·

답변을 작성해보세요.

1

kd park님의 프로필

kd park

질문자

2020.11.06

잘 이해되었습니다. 감사합니다.

0

안녕하세요. kd park님 좋은 질문입니다.

먼저 첫번째 질문부터 답을 드릴께요.

대부분의 비즈니스는 10번 조회가 일어나고 1번 쓰기가 일어납니다. 게시판을 생각해보면 글을 쓰는 사람보다는 글을 읽는 사람이 훨씬 많지요. 그래서 대부분의 성능 이슈는 이런 대량의 조회에 중점을 맞추어야 합니다.

그리고 대량의 조회중에서도 게시판 리스트 처럼 여러 데이터를 읽기로 가져 오는 부분이 병목이 됩니다.

반면에 데이터를 PK로 하나씩 찍어서 조회하는 경우에는 DB가 매우 빠르게 조회하기 때문에, 성능 이슈가 되는 경우는 거의 없습니다.

따라서 쓰기안에서 PK를 중심으로 한두번 읽기가 더 발생한다고 해서 전체 애플리케이션에 미치는 영향은 미미합니다.

추가로 성능에 미치는 영향이 미미해서 잘 사용하지는 않지만, 해당 부분도 프록시를 통해서 읽으면 select 쿼리를 줄일 수 있습니다.(JPA 기본편 프록시에서 설명)

그 다음 두번째 부분에 답을 드릴께요.

게시판에 댓글을 추가할 때 다음과 같은 방법은 사실 잘못된 설계로 이해하시면 됩니다.

board.getComments.add(comment);

지금처럼 댓글이 매우 양도 많고, 비즈니스상 중요하면 댓글도 명확하게 하나의 중심 엔티티로 잡고 설계해야 합니다.

CommentRepository.save(comment); 처럼 설계해야 합니다.

그리고 board -> comment의 연관관계도 끊어버리는 것이 좋습니다. 반대로 comment -> board의 관계는 유지해도 됩니다.

감사합니다.