인프런 커뮤니티 질문&답변

안녕하세요 spring / jpa 관련해서 김영한님 강의 수강하면서 공부중인 대학생입니다!
querydsl 강의의 절반정도 까지 들은 시점에서 궁금증이 생겨 처음으로 질문남깁니다.

Member, Product 엔티티들의 다대다 관계를 설명해주는
MemberProduct  엔티티가 존재한다고 생각했을때,
MemberProduct 엔티티를 새로 생성해 Member 와 Product의 관계를 하나 만들어 주는 과정에서 성능관련 질문이 있습니다.

지금까지 배운 내용으로는 실제 서비스에서 아래의 5단계를 통해 관계를 생성한다고 이해하고 있습니다.

1. MemberProduct  엔티티를 생성하기 위해 특정한 post 메서드의 api 실행

2. api의 parameter 로 Member id, Product id (혹은 id가 아니더라도 엔티티의 유일성을 특정할 수 있는 어떤 값)를 전달받음

3. 전달 받은 memberId 와 productId를 이용해 memberRepository와 productRepository 를 이용
특정한 Member/ Product 엔티티를 가져옴 (이 경우 2번의 db 조회)

4. 가져온 Member / Product 엔티티를 이용하여 new MemberProduct(member, product, 그외 필드) 와 같은 방식으로 MemberProduct 엔티티 생성

5. memberProductRepository.save 이용하여 관계 저장

 이때 3번 단계에서 member 와 product를 findById 같은 메서드를 이용해 찾아오는 과정에서 불필요한 네트워크 호출이 생기는 것이 아닌가 라는 생각이 들어 질문 드립니다.

 productId 를 이용해 product를 조회할때는 디비에 존재하지 않는 product에 대해서 연관관계를 만드는 경우를 대비해서 디비에 존재하는지 확인차 조회해야한다.. 라는 생각이 들지만,
 memberId 같은 경우는 실제 서비스에서는(저는 실무 경험이 없어서 정확하게는 모르겠습니다..) security의 인증을 통해 jwt에서 디코딩해서 전달받거나 혹은 다른 인증방법을 통해 안전하게 전달받는다는 생각이 들어 굳이 member 가 존재하는지를 확인하기 위해 memberRepository를 이용해 디비에서 조회를 해야하나라는 생각이 들었습니다.

 또한 querydsl 을 수강하기 전까지는 MemberProduct에 반드시 Member 타입의 필드가 있어야지 조인의 기준이 정확해져서 쿼리를 날릴때 도움이 되겠다라는 생각도 했지만,
 querydsl 을 이용하면 Member member필드대신  Long memberId 필드를 MemberProduct에 넣어서 테이블 조인의 기준으로 사용해도 어렵지 않을것 같다는 생각이 듭니다.
 물론 Member member필드대신  Long memberId 필드를 이용하고 DDL AUTO 를 사용하면 db에 정합성 문제가 생기겠지만, database는 어차피 둘다 똑같이 bigint 타입의 컬럼으로 인식하기 때문에 직접 ddl을 설정해주면 정합성 문제는 해결될것같습니다.

위와 같은 문제가 실제 서비스에서 고려되는 정도의 성능 문제를 야기하는지, 
만약에 실제 서비스에서 고려되는 문제라서 엔티티 대신 엔티티의 primary key를 필드로 이용해 관계를 만든다면, 어떤 문제가 발생하는지,
그렇게 만든 관계 엔티티에서는 domain driven dev관점에서 어떻게 해야할지가 궁금합니다.

작년 연말에 우아한테크콘서트도 재미있게 봤습니다
긴 질문 읽어주셔서 감사합니다!