양방향 연관관계 건의

[JIWEON-JEONG]

양방향 연관관계

양방향 연관관계를 통해 얻을 수 있는 이점은 N+1 문제를 해결 할 수 있는 FetchJoin 을 사용 할 수 있다는 점입니다.

그에 반해 단점으로는 객체 생성 및 업데이트 , 삭제 시 mappedBy 로 매핑되어있는 데이터를 최신화 시켜줘야 하고,
실제 Brand CRUD 에서 발생한 것 처럼 무한루프 에 빠질수 있고,
매핑 데이터들(예를 들어 places) 은 결국 JVM 내의 메모리를 잡아 먹습니다.

이러한 점에서 양방향 연관관계가 정말 필요한 객체들만 , 즉 역방향으로 조회해야 하는 객체들만 관계를 맺어줘야 한다고 생각하여
해당 부분에 대해 건의 드립니다.

아래 제 의견들은 양방향 관계를 정말 필요할 경우에만 쓰자. 라는 전제가 깔려있습니다.

프로젝트 도메인 별 정리

User 와 Place

User 를 통해 Place 를 가져 오는 것은 일단 제가 생각하기엔 "내가 생성한 장소" 의 기능에 사용 할 수 있을거같습니다.
Place 데이터가 굉장히 많아져서 , 그 많은 Place 데이터 중에서 해당 유저가 쓴 장소를 찾는것이 부하가 클경우, 양방향 연관관계로
해소 할 수 있습니다.

하지만 이건 Place 데이터가 충분히 많아질 경우 양방향 관계로 바꿔줘도 된다. 라는 생각입니다.
내가 생성한 장소기능을 api/places/userId 와 같이 설계 할 수 있습니다.
추후에 양방향으로 바꾸는 것은 그리 복잡한 작업은 아니니 ,
장소 데이터가 생성 또는 변경 될때마다 매핑되어있는 데이터를 계속 업데이트 해주고 객체 관계 가 복잡해지는 리소스를 없애는게
현시점에서 더 낫다는 생각이 들었습니다.
결론은 User 와 Place OneToMany 관계를 제거 해야한다는 의견입니다.

User 와 Brand

User 가 생성한 브랜드를 User 를 타고 조회 할일이 없어 보입니다.
해당 부분도 양방향 관계를 제거 해야 한다는 의견입니다.

User 와 Review

User 와 Place 의 경우와 같습니다.
추후 데이터가 많아질 경우 성능 리팩토링으로 고려 할 순 있어도 ,
현재는 단방향 매핑만으로 충분히 구현 가능하기 때문에 이부분도 제거 해야한다는 의견입니다.

Brand 와 Place

Brand 를 통해 Place 를 조회 할일은 먼저 내 주변 장소를 찾을때는 필요 없다고 생각합니다.
결국 GridApi 를 통해 불러와야 하기 때문에 내 주변 어떤 브랜드 위주로 찾겠다 해도 Grid API 에 브랜드 제약을 거는 식으로 구현 할 수 있습니다.


다만 현재 내 주변이 아니라 예를 들어서 제주도에 여행을 가는데 내가 찾는 브랜드가 제주도에 있는지 없는지 를 보고 싶을 경우 ,
즉 해당 브랜드가 가지고 있는 지점을 보고 싶을 경우 양방향 연관관계가 필요 할 수 있습니다.


이부분은 당장에 필요 하지 않으니 나중에 추가 해도 된다 라는 생각을 갖고 있고
팀원 분들 의견 궁금합니다.

Place 와 Review

이 부분에서는 장단점이 있을거같습니다.
Place 를 통해 Review 를 조회 하는 일은 많은 거라 생각합니다.
하지만 이부분을 Review API 로 분리 하여 구현 할 수 있습니다.


양방향 관계를 맺어서 얻을 수 있는 이점으로는 (아래와 같은 그림으로 만들때)

1. 두번의 API 호출을 안 할 수 있습니다. (네트워크 비용 감소)
2. DB connection 비용 감소.

단점 으로는

1. 페이징으로 구현 하게 될때, 위 장소 데이터는 똑같은데 계속 받아와야 하는 문제발생.
2. 양방향 연관관계의 단점들

이러한 이유에서 이 부분도 제거 해야 된다고 생각합니다.

댓글로 생각 말씀해주시면 감사하겠습니다.

[siner308]

Lazy Loading 자체를 안쓰고 쿼리 빌더에서 명시적으로 join을 거는게 좋을것같아요
그렇게 하면 이러한 양방향 등의 다양한 케이스에서 orm 설정에 괴롭지 않아도 될것같구요
원치 않는 lazy loading으로 인해 생기는 사이드이펙트를 방지하면 좋겠습니다.

[JIWEON-JEONG]

Lazy Loading 자체를 안쓰고 쿼리 빌더에서 명시적으로 join을 거는게 좋을것같아요 그렇게 하면 이러한 양방향 등의 다양한 케이스에서 orm 설정에 괴롭지 않아도 될것같구요 원치 않는 lazy loading으로 인해 생기는 사이드이펙트를 방지하면 좋겠습니다.

그 말씀은 양방향 연관관계를 쓰지 말자 라는 말씀인가요?
저의 주장의 요점은 양방향관계가 기존에 이미 잡혀있어서 어떤 기능을 개발하려고 할때,
데이터 정합성을 위한 추가적인 메서드 (연관관계 편의 메서드 라고 부르기도 함) 나 객체들의 의존관계가 복잡해져서
이런 부분을 안고 갈만큼 양방향 관계가 필요한가? 였습니다!

[JIWEON-JEONG]

09/27 오프라인 미팅 -> 양방향 연관관계 일단은 사용하지 않고 추후 필요할시 도입