<성능최적화 순서>
1. DTO클래스를 만든다(필수!!!! entity 와 api 스펙을 분리하여 유연한 설계를 하기위함!)
2. fetch join을 이용한다
3. 필요하다면 dto직접반환쿼리를 짜본다 (단, 이 경우 - 따로 Repository를 작성하길 권장함. 프레젠테이션레이어의 로직이 들어가기 때문에)
-> 이 방법 - 과연 어느정도까지 성능최적화가 되는가?? 에 대해서는 테스트해보아야 한다. 컬럼 몇개 select에서 뺀다고 그렇게까지 급격한 성능최적화가 되지는 않음. 결국엔 조인을 하는 거 자체에서 성능이~~~!!
<join fetch와 join차이>
1. join fetch : 순수한 엔티티 그대로 가져온다.
2. join : 필요한 특정 컬럼만 뽑을 때 사용한다.
<스프링 data JPA의 @Modifying 어노테이션?>
엔티티매니저가 쿼리를 땡겨올때 select해서 결과값 가져오는 게 있고. update나 delete처럼 단순히 실행한 결과의 갯수를 가져오는 것이 있다( 결국엔 executeQuery랑 executeUpdate 인 것) - 이에 따라 . @Modifying 어노테이션을 붙여서 - 이것은 조회가 아니라 업데이트용입니다. 라고 명시해주는 것이다.
<@Transactional 어노테이션>
나는 스프링 data JPA를 사용하면서 이 어노테이션을 사용한 적이 손에 꼽는다 ( 여러 트랜잭션을 하나로 묶어야 하는 상황제외) - 왜 였냐면!! 알고보니 이미 JpaRepository구현체가 @Transactional어노테이션을 전부 걸어주었었던 것이다!!!
참고로 - 기본값은 @Transactional(readOnly = True) 로 되어있고. save같이 영속성컨텍스트랑 비교해야하는 경우에는 다시 @Transactional 덮어쓰기 해두었더라.
readOnly = True일 경우, 영속성컨텍스트에 초기화한 객체 넣어두고 비교하는 과정을 거치지 않기 때문에 약간의 성능최적화가 있다고 한다.
<JPA에서 상속관계를 풀어내는 법>
1. 일반상속 :
1) 테이블 하나에 전체 컬럼 때려박기(Single table전략)
2) 각각의 테이블로 만들고 - join해서 가져오는 방식 (Joined 전략)
이때에는 abstract 클래스로 부모 클래스 만들고 - extends해서 하위클래스들 각각 만들고.
@Inheritance관련 어노테이션을 활용하면 된다.
DTYPE이라는 컬럼이 자동적으로 추가된다. 옵션으로 컬럼명 바꾸거나 DTYPE안에 들어가는 변수 명 바꿀 수 있음.
https://ict-nroo.tistory.com/128
2. 공통 컬럼 상속 :
이 경우에는. 상속 이라는 특성을 이용하기는 하지만 - 도메인 내용과는 관계 없고. 그냥 중복코드를 제거하는 의미에서의 상속.
이를 테면 createdDate , updateDate같은 컬럼은 대개 모든 엔티티에 포함되므로 - 이러한 엔티티를 abstract클래스인 BaseEntity로 만들고, 상속하게 하는 방식.
@EnableJpaAuditing 이용. 스프링 data JPA를 사용하면 어노테이션만으로 createdDate랑 @updateDate만들수있음.
@MappedBySuperClass어노테이션 : 나는 실제테이블이 아니얌~~ 만들지 마시오! 라는 뜻.
