inflearn logo
강의

강의

N
챌린지

챌린지

멘토링

멘토링

N
클립

클립

로드맵

로드맵

지식공유

자바 ORM 표준 JPA 프로그래밍 - 기본편

many to many entity 생성관련 질문

294

[20_HG005Y]안세현

작성한 질문수 1

0

안녕하세요 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관점에서 어떻게 해야할지가 궁금합니다.

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

java JPA

답변 2

1

[20_HG005Y]안세현

헉.. 동일한 내용의 질문이 있었군요.
궁금했던 부분이 명확해졌습니다 감사합니다!

0

김영한

안녕하세요. 세현님^^

사실 이런 부분은 애플리케이션 전체로 보면 성능에 영향을 주는 부분이 미미합니다. 대부분의 비즈니스가 조회가 많고 등록 같은 부분은 매우 적기 때문이지요.

그리고 엔티티 하나를 인덱스를 정확하게 찍어서 DB에서 조회하는 경우에도 성능에 영향을 주는 부분은 미미합니다.

그래도 성능상 최적화를 하고 싶으면 프록시를 사용하면 됩니다.

예를 들어서 3번의 경우에도 Member, Product를 조회할 때 프록시로 조회하시면 됩니다. 프록시는 PK(@Id)를 가지고 있기 때문에 PK만 사용한다면 실제 엔티티를 DB에서 조회하지 않습니다.

이렇게 프록시를 사용하면 고민하셨던 성능 문제를 대부분 해결할 수 있습니다.

JPA 강의의 프록시와 다음 내용도 참고해보시면 도움이 되실거에요.

https://www.inflearn.com/questions/204850

감사합니다.

벌크연산에서 member.getAge 호출 시 영속성 컨텍스트에서 데이터를 가져오는건가요?

0

33

2

inheritance startegy 선택시 고려사항

0

24

1

Entity 동등성 비교

0

24

1

실무 조언 관련 질문입니다.

0

48

1

H2데이터베이스 파일 생성

0

59

2

서브쿼리 강의에서 ALL 예시 관련 질문드립니다.

0

57

2

수정또는 삭제시 영속성 엔티티에 값이 무조건 있어야 하나요?

0

58

1

JPQL 메소드와 락

0

56

1

Delivery @OneToOne

0

62

1

17강 4~5분대 테이블 값 조회가 안됩니다.

0

98

2

UnsupportedOperationException 발생

0

89

3

H2 Database 연결이 안됩니다.

0

98

2

연관관계 매핑 질문드립니다.

0

88

2

h2데이터베이스 실행오류

0

110

2

persistence.xml

0

112

2

양방향 연관관계에서 연관관계의 주인(mappedBy)을 왜 꼭 정해야 하나요?

0

83

1

영속성 컨텍스트

0

70

1

JPA 프록시

0

100

1

Native Query와 MyBatis

0

74

1

영속성 컨텍스트는 어떤 메모리에 저장되는건가요?

0

93

1

임베디드 타입 예시 코드 관련 질문

0

121

3

명시적 조인에서 별칭을 주면 왜 객체에 접근할 수 있나요

0

96

3

인텔리제이 패키지 커서 단축키 질문

0

109

2

혹시 현재는 ID 데이터 타입이 String이면 안되나요?

0

149

1