엔티티들을 어떻게 연결시킬까?

[nayonsoso]

FK 유/무? 객체참조/long참조?

[nayonsoso]

• 연관된 객체를 사용했을 때 조회에서 얻는 이점이 있긴하다. "간결한 코드"
  - Board board = boardRepository.findByBoardCode(post.getBoardCode()); 보다
  • Board board = post.getBoard(); 가 간결하다.
    • 양방향은 실수의 여지가 많다.
    • 어디까지 타고타고 갈지 파악하기 어렵다. 직접 쿼리를 보기 전까지 예측이 힘들다.
    • 실제로 우리 프로젝트에서, 양방향 + EAGER를 엄청 썼더니 updateMyPageInfo 메서드를 호출할 때
      사용자가 작성한 게시물(post)와 댓글(comment)까지 영속화된 적이 있었다.
  • 지금도 위시 대학 목록을 조회할 때, region 이랑 country 까지 fetchJoin 해온다.
  • 양방향 싱크를 맞추기 위한 코드를 개발자가 직접 작성해야한다 -> 누락의 여지가 있다.
• 연관된 객체를 사용하면, JPA의 영역이므로 JPA의 도움을 받을 수 있다.
  - e.g. Post 와 Board의 관계에서 List<Post>에 대해 각각의 Board도 함께 조회하고 싶다.
  • 원시값으로 참조할 때
    • for(List<Post> posts: post) { boardRepository.findByBoardCode(post.getBoardCode()); } → N+1 발생
    • N+1을 피하려면
      List<String> boardCodes = posts.stream().map(p -> p.getBoardCode()).toList();
      List<Board> boards = boardRepository.findAllIn(boardCodes);
      Map<Board, Post> = boards.stream().map(어쩌고..) 를 해야함
  • @entitygraph(attributePaths = "board") List<Post> findAllWithBoard(); → N+1 해결
• 반드시 연관되어 조회되는 것들은 양방향이 더 성능이 좋다.
  - Post에서 List<Comment>를 관리하면 조회시 로직이 아주 간단해진다.
  - JPA의 기능(BatchSize)등을 활용하면 N+1의 걱정도 없다.
• 연관관계를 사용했을 때 걱정되는 점: "조회 편의"를 위한 설정을 엔티티에서 해도 되는것인가?
  - '연관된 엔티티 조회시 JPA가 주는 편의성'을 사용하는게 목적이라면, 레포지토리에서 해도 충분하지 않나?
  - 하지만 long 으로 참조하고 있다면 JPA의 기능 사용에 제한이 있음 (e.g. EntityGraph 사용 불가)
  JPQL fetch join 을 사용할 수 있지만, 연관된 엔티티를 하나로 묶어서 가져오려면 Projection 이 필요하거나, 서비스레이어에서 매핑이 추가적으로 필요함.
• fetchType을 EAGER로 하면, 불필요한 영속화가 일어난다.
  - 필요할 때만 영속화하도록 LAZY로 통일하자.
  - 통일하는게 좋겠다 생각한 이유 : 연관관계를 사용했을 때의 단점인
  "fetchType 뭘로 설정할지 하나하나 따져가며 결정하기 위한 고민 리소스 소요"를 최소화하자.
  - 연관된 엔티티를 함께 사용할게 명백하다면,
  - 그래도 대부분의 경우에는 따로 쿼리 나가도록 두자. 큰 일이 아니라면
  - 성능에 영향이 있을것이라 생각된다면(예를들어 N+1 발생), fetchJoin하자.
  - 다른 말로 정리하자면,
  ORM 으로 일어나는 성능 문제는 레포지토리에서 해결하게하자.
  도메인에서는 미리 정의해두지 말자. 열어두자.

[Gyuhyeok99]

잘 정리해주셔서 감사합니다! 🙇
특히 연관된 객체를 사용할 때의 편의성과 성능 관련 이슈들을 잘 짚어주신 것 같아요.

저도 연관된 엔티티 중 생명주기가 명확히 함께하는 경우엔 객체 참조가 적절하고,
그 외 경우엔 id 기반 참조가 유지보수 등에서 더 유리하다고 생각합니다.

지난 회의에서 객체 참조를 사용할 땐 양방향으로 통일하자는 방향으로 정리되긴 했지만,
이 부분은 여전히 조금 고민이 되는 지점이긴 한 것 같아요. 🥲 정말 어렵네요...

그래서 이 부분은 나중에 구조 변화나 실사용 중 문제가 생기면 그때 다시 한 번 논의해보면 좋을 것 같다는 생각입니다!