Spring JPA의 사실과 오해

https://www.youtube.com/watch?v=rYj8PLIE6-k&list=PL42XJKPNDepZVLkCM4yEKmU4LHyXjzChy&index=8 

 

 

테이블은 정규화를 하여 최소한의 데이터를 높은 성능으로 조회, 변경한다.

Entity는 식별자와 생명주기를 가지며, 연관관계는 참조 값으로 만든다.

테이블은 외래키 하나로 양방향 참조가 가능하지만

Entity는 불가능하다. 각각 참조를 가지고 있어야한다.

 

테이블의 외래키를 가지고 있는 주인은 1개지만

Entity는 2개이다. 그게 아니면 단방향으로 하거나

 

📑 보통은 단방향으로 충분하다.

맞는 말이다.

 

중간에 Cascade로 영속성 상태 전이가 가능하다.

 

memberDetail에서 member를 등록해주면, 알아서 전파되어 Member 테이블에도 insert 된다.

 

 

물론 반대방향 (1:N)도 마찬가지

다만 외래키의 주인이 아니므로, Member를 먼저 저장해서 외래키를 생성해야한다.

하지만 위의 코드는 기대한대로 동작하지 않는다.

추가적인 update 쿼리가 2개 찍혔다.

외래키를 지정하기 위해서 추가적인 update 쿼리가 필요하다.

생각해보면 당연한 일. member 키를 가져올 때 insert, 이후 외래키 지정할때 update가 필요.

단방향이 무조건 좋은게 아니라 위험해서 그렇다.

이 경우에는 양방향으로 해주는게 좋다.

기본키를 외래키로 사용한다면 @MapsId로 연관관계 주인을 지정. (JoinColumn 불가능)

이렇게 일대다 관계를 양방향으로 바꾸면, 업데이트 쿼리가 추가적으로 발생하지 않는다.

cascade를 쓰는경우에는 그렇다.

 

 

---

📑 연관관계 매핑전략

N+1은 ORM에서 자주 발생하는 문제.

 

참고로 시점의 차이일 뿐, Lazy도 N+1 문제가 발생한다. (물론 실제 참조가 일어나는 시점에 발생)

 

페이지네이션 쿼리에 fetch Join = 존나 위험하다.

우리가 쿼리를 할 때에는 Limit 개수만 가져올거 같지만 fetch 조인이 적용되면 페이지 범위 내에 얼만큼의 레코드가 들어가는지 알기 어려움. 그래서 Limit 조건이 없이 다 가져오고, 메모리에서 원하는 페이지만 반환하기도함.

 

하이버네이트만으로는 문제가 없어보이지만, DB쪽에서는 쿼리가 미친듯이 찍히는거임 ㅎㅎ.. 분리해야한다.

 

 

📑 Spring Data JPA 기능

Repository는 JPA는 없는 개념이다.

 

JOIN쿼리는 꼭 JPQL 이런걸 써야하나요?

 

어...이름이 다른가요? (* 쿼리는 같음)

 

리턴 타입이 다르다. (Page Slice). 이 둘의차이는 무엇일까

상속관계! Page가 상위! (전체 페이지 수, 전체 엘리먼트 수를 가짐)

 

Page는 쿼리가 2개 찍힌다 (Count)
Slice는 카운트 쿼리가 없다. 그럼 다음페이지 여부는 어떻게 알아요..?

➡ limit가 우리가 적은 것 보다 하나 더가져옴.(있으면 다음 값이 있는거)

테이블 레코드가 오지게많아서, Count가 부담스럽다면 Slice도 고려해보라

다만 Page를 사용하는 경우에도 Limit 보다 적게 반환되면 Count가 나가지 않음. 그건 참고

 

 

 

꼬롬하게 사용하기

DTO를 만들어야한다? (또는 QueryDSL 같은곳에서 프로젝션 기능을 이용?)

 

는 됩니다.

final로 선언된 값을 Repository의 반환값으로 사용시

뭘 좋아할지 몰라서 Dynamic Projection으로 준비해봤습니다.