양방향 연관관계 VS 단방향 연관관계 X Join 쿼리
목차
- 개요
- 양방향 연관관계를 언제 써야할까?
- 양방향 연관관계를 꼭 써야할까?
- 무슨 장단점이 있을까?
- 그럼 reciptopia에서는 어떻게 해야 하나?
- pullgo에선 어떻게 했었나
개요
거의 모든 연관관계가 양방향이다
이게 맞나?
사실 초기 기획에서 Join을 통한 검색 및 조회를 전혀 염두에 두지 않아서 생긴문제
특정 엔티티에서 다른 엔티티를 조회하는 방법이 연관관계라고 생각했었다.
즉 조회가 필요한 방향의 모든 연관관계를 만들어 주었다.
어? 그런데 Join을 사용하면 되네?
그래서 이게 문제가 있나?
위의 도메인보다 더욱 복잡해것이 실제 코드다
위와 같이 단순히 연관관계를 위한 필드 뿐만아니라
각각의 관계편의 메소드가 추가되어 코드가 더더욱 복잡해진다
양방향 연관관계를 안쓰면?
단방향이어도 테이블 관계 상에서 양방향 조회가 모두 가능하다.
따라서 단방향 연관관계와 쿼리를 이용하면 가능하다!
그러면 양방향 연관관계는 언제 써야 할까?
이 질문과 유사한 의도의 질문이 존재하여 답변을 일부 인용했다
Q
그냥 단방향 매핑으로 모든 거 처리하고, 필요할때만 sql join query 날려서 join해서 불러오면 되는거 아냐? 라는 생각도 드는데요..
A
네 그렇게 해도 됩니다^^!
그런데 실제 개발을 해보면 복잡한 조회 쿼리에서 양방향 매핑을 하고 싶은 경우가 발생합니다.
예를 들어서 team 1:N member 이런 관계가 있을 때 team과 member를 fetch join으로 한번에 조회하고 싶은 경우가 있습니다.
이럴 때 양방향 매핑이 필요합니다.
원문
즉 양방향 연관관계를 꼭 써야할 필요는 없는것 같다
무슨 장단점이 있을까?
단방향 X Join 사용시
장점
- 단순해지는 도메인 코드
연관관계 메소드를 잘못만들어 재귀호출 문제를 겪지 않아도 될것이고
도메인 코드가 단순해질것이다
단점
- 외래키를 갖고있지 않은쪽에서의 삭제를 전파해 주어야 할 때
외래키로 연관되어 있는 엔티티의 삭제를 직접 해주어야 한다
ex) 계정이 삭제될때 해당 유저가 작성한 게시글도 삭제되어야 하는 경우
특정엔티티의 비지니스로직이 있는 Service 레이어에서 해당 엔티티의 Repository가 아닌 외래키를 갖고있는 엔티티의 Repository에 접근하여 삭제해주어야한다
그러면 하나의 Service에 여러 Repository에 대한 의존은 좋지 않을까?
결론부터 말하자면 그렇다고 볼 수는 없다.
다른 포스트에서 다룬 문제다
연관관계 삭제는 어떻게하지?
이것도 다른 포스트에서 다룬 문제다
