방개의 놀이터

상속관계 매핑 

   관계형 데이터베이스는 상속관계가 없다 

   슈퍼타입 서브타입 관계라는 모델링 기업이 객체 상속과 유사

   상속관계 매핑: 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑 

@DiscriminatorColumn

디타입 

디비만 쿼리 나렷을때 앨범때문에 들어왔는지 무비인지 알수가 없기 때문에 

그렇기 때문에 디타입은 웬만하면 넣어두는게 낫다

@DiscriminatorValue("B")

테이블마다 디타입에 들어갈 이름을 정할 수 있다 

@MappedSuperclass 

  상속관계 매핑하고 관계가 없다. 

  공통 매핑 정보다 필요할 때 사용 (id, name) 

   조회 검색불가 (em.find(BaseEntity)불가)

  직접 생성해서 사용할 일이 없으므로 추상 클래스 권장 

단일테이블 

   1. 조인이 필요가 없다 

   2.  조회 쿼리가 단순함 

  단점 

  1. 자식 엔티티가 매핑한 컬럼은 모두 null 허용 - 데이터 무결성의 입장에서는 좀 그렇다. 

  2. 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다. 상황에 따라서 조회 성능이 오히려 느려질 수 있다. 

@Entity

@Entity 가 붙은클래스는 JPA가 관리 엔티티라고 한다. 

JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수 

주의 기본 생성자 필수(파라미터가 없는 public또는 protected생성자) 

final 클래스, enum, interface, inner 클래스 사용 x 

저장할 필드에 final 사용x 

name: 매핑할 테이블 이름 - 엔티티 이름을 사용 

catalog 데이터베이스 catalog 매핑 

schema 데이터 베이스 schema 매핑 

UnipqueContrraints DDL 생성시 제약 조건 

데이터베이스 시키마 자동 생성 

DDL을 애플리케이션 실행 시점에 자동 생성  - 생성 변경 삭제 

테이블 중심 -> 객체 중심 

데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성 

이렇게 생성된 DDL은 개발 장비에서만 사용 

생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용 

주의 사항

운영장비에는 절대 create, create-drop, update를 사용하면 안된다. 

개발 초기 단계는 create 또는 update 

테스트 서버는 update 또는 validate 

스테이징과 운영서버는 validate 또는 none 

운영같은 경우는 데이터가 몇천건 있는 상태에서 alter를 잘못치면은 시스템이 중단이 된다. 

운영단계에서 alter을 시스템이 자동으로 쳐주는게 위험하기 때문 

JPA 소개

EJB  엔티티빈(자바 표준): 객체를 저장, 조회하는 것 

하이버네이트(오픈 소스) :  빠르게 만드는 장점이 있다. 

JPA(자바표준): 여러사람의 의견을 모운다(표준) 오픈소스에서 출발한거이기 때문에 탄생 좋다. 

역사가 있고 사랑을 많이 받았기 때문에 JPA는 좋다. 

표준명세 

-JPA인터페이스의 모음 

-JPA 2.1표준 명세를 구현한 3가지 구현체 

-하이버네이트, EclipseLink, DataNucleus 

애플리케이션 ------자동 -----> JPA 표준 인터페이스 ( 하이버네이트, EclipseLink, DataNucleus) 

JPA 버전 

JPA1.0 :초기버전 복합 키와 연관관계 기능이 부족 

JPA2.0: 대부분 ORM 기능을 포함 JPA  Criteria 추가 

JPA2.1: 스토어드 프로시저 접근, 컨버터(Converter), 엔티티 그래프 기능 추가 

JPA를 왜 사용해야 하는가? 

1. SQL 중심적인 개발에서 객체 중심으로 개발 
2. 생산성 
3. 유지보수 
4. 패러다임 불일치 해결 
5. 성능 
6. 데이터 접근 추상화와 벤더 접근성 

JPA 생산성

1. 저장: jpa.persist(member) 
2. 조회: jpa.find(memberId)
3. 수정:member.setName("변경할 이름") 
4. 삭제: jpa.remove(member)   

SQL은 JPA가 처리하기 때문에 JPA는 필드만 추가하면 된다. 

조인도 다 해준다.  

JPA의 성능 최적화 기능 

1. 1차 캐시와 동일성 보장 

2. 트랜잭션을 지원하는 쓰기 지연(transactional wirte-behind)

3. 지연 로딩(Lazy Loading) 

트랜잭션을 지원하는 쓰기 지연 - Insert 

1. 트랜잭션을 커밋할 때까지 insert SQL을 모음 

2. JDBC BATCH SQL기능을 사용해서 한번에 SQL 전송 

transaction.commit(); - 이때 데이터 베이스에 SQL을 보낸다. 

ORM 관계형 맵핑 

1. 객체지향

2. 관계형 데이터베이스 

를 잘 알아야 한다. 

스프링 데이터 JPA 구현체 분석 

@Repository -> 1. 스프링 빈의 콤포넌트 대상 
2. JPA 예외가 터지면 연속성 대칭에 있는 예외들은 exception을 보면 스프링에서 쓸수있는 예외로 다 바꿔준다. 
하부 기존 기술을 바꿔도 영향이 가지 않는다. 

@Transaction (readyOnly = true)
SPring JPA 는 트랜잭션에 걸고 시작한다. 
트랜잭션을 이어받아서 시작한다. 

영속성 컨텍스트? 트랜잭션이 끝나면은 없어진다. 
조회는 리드온니 





트랜잭션이 끝날때 플러시를해서 디비에 커밋한다 
리드온리 트루가 있으면 플러시를 안한다 비디에 변경감지를 안보내겠다 왜냐하면 리드온니니까 -> 더티체킹이 생략되기때문에 약간의 성능향상을 느낄 수 있다. 

세이브 메서드 
새로운 앤티티면 persis로 저장 
새로운 앤티티가 아니면 병합 merge 
데이터변경은 변경감지를 해야하는데 머지르 쓰면 안됨 
머지는 업데이트용이 아닌 영속상태의 엔티티가 어떤상태가 벗어나면 다시 그 상태로 돌아가기 위해서?? 




Query by Example 
prob장점 
쿼리를 생성하는데 사용 

1. 동적 쿼리를 편리하게 처리 
2. 도메인 객체를 그대로 사용 
3. 데터 저장소를 RDB에서 NOSQL로 변경해도 코드 변경이 없게 추상화 되어 있음 
4. 스프링 데이터 JPA repository 인터페이스에 이미 포함 

단점 
1. 조인은 가능하지만 내부 조인(Inner join)만 가능함 외부조인(Left join)은 안됨 
2. 다음과 같은 중첩 제약조건 안됨 
firstname = ?0 or (firstname = ?1 and lastname = ?2)
3. 매칭 조건이 매우 단순함 
문자는 starts/contains/ends/regex
다른 속성은 정확한 매칭( = )만 지원

정리 
실무에서 사용하기에는 매칭 조건이 너무 단순하고, LEFT 조인이 안됨 
실무에서는 QueryDSL을 사용하자. 

Projections 
인터페이스만 만들어두면 구현체는 스프링 데이터 JPA가 만들어준다 


네이티브 쿼리 

가급적 네이트브 쿼리는 사용하지 않는게 좋음 -> 복잡하다 
제약
Sort 파라미터를 통한 정렬이 정상 동작하지 않을 수 있음(믿지 말고 직접 처리)
JPQL처럼 애플리케이션 로딩 시점에 문법 확인 불가 -> ㄴ이름없는 네임드 쿼리 
동적 쿼리 불가 

JPA 네이티브 SQL지원