스프링 39강. @ManyToOne 기본 전략이 EAGER인 이유

 

 

Post  1  ->  User  1

 

하나의 글은 한 명의 유저가 쓴다.

 

Post  N  <-  User  1

 

한 명의 유저는 여러 개의 글을 쓴다.

 

 

Post  (N)  :  User  (1) 의 연관 관계를 갖는다.

 

FK의 주인은 Post 테이블(N)이고,

드라이빙 테이블도 Post 테이블(N)이다.

 

---

 

만약 다음과 같은 페이지 두 개만 존재하는 사이트에

list 페이지에는 Post 테이블의 title만 필요하고,

detail 페이지에는 Post 테이블의 title, content만 필요하다고 할 때

User 테이블에는 접근을 하지 않으므로

LAZY 전략이 훨씬 좋을 것이다.

근데 왜 @ManyToOne의 기본 fetch 전략이 EAGER일까?

 

Post를 SELECT 했을 때 User 데이터는 한 건 뿐이기 때문이다.

크게 부하가 없기 때문에 기본전략이 EAGER이다.

 

만약 SELECT 결과가 100개로 컬렉션을 돌려준다면

기본전략이 LAZY일 것이다.

 

---

 

한가지 예를 들어보자.

 

아들이 소풍을 가는 날이다.

 

"엄마, 내가 친구들이랑 김밥을 먹을 수도 있고, 안 먹을 수도 있는데

100줄만 미리 싸주세요!!"

 

과연 아들에게 100줄을 다 싸줄까?

먹을지 안 먹을지도 모르는데?

 

그렇다면 아들이

"엄마, 내가 친구들이랑 김밥을 먹을 수도 있고, 안 먹을 수도 있는데

1줄만 미리 싸주세요!!"

 

싸줄 것이다.

 

이때 100줄을 미리 다 싸주는 상황에서는 아들에게 돈을 쥐어주고

"혹시 먹게 되면 이 돈으로 100줄 사 먹어"라고 할 것이다.

LAZY 하게.

 

김밥 1줄을 미리 싸주는 것은 엄마에게 크게 부하가 없기 때문에

미리 싸줄 수 있다.

이게 @ManyToOne의 EAGER 전략이다.

 

김밥 100줄이 필요할지 안 할지 모르는데 만약 필요하면

돈 주고 100줄을 사 먹는 게

@OneToMany LAZY 전략이다.

 

@ManyToOne 기본 전략 : EAGER

@OneToMany 기본 전략 : LAZY

 

@ManyToOne이어도 앞서 설명한 사진처럼

User 데이터를 끌어올 필요 없는 상황이라면

전략을 LAZY로 바꿔도 상관없다!

 

 

 

[출처]

 

https://cafe.naver.com/metacoding

메타코딩 : 네이버 카페

메타 코딩 유튜브

https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9

메타코딩