[JPA] Entity 매핑

엔티티티 프래졀~ 엔티티티티~ 프레졀 프레졀~ 

(정색)

---

 

객체와 테이블 매핑

- @Entity가 붙으면 JPA가 관리한다.

- 기본 생성자가 꼭 있어야 한다.

- final zmffotm, enum, interface, inner 클래스 X

 

 

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

- DDL 애플리케이션 실행 시점에 자동 생성

- hibernate.hbm2ddl.auto 옵션

    - create : 기존 테이블 삭제 후 다시 생성 (DROP + CREATE)

    - create-drop : create와 같으나 종료시점에 테이블 drop

    - update : 바뀐 것만 추가 (alter)

    - validate : 엔티티와 테이블이 정상 매핑되었는지만 확인

    - none : 사용하지 않음

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

     개발 초기 create, update

     테스트 update, validate

     스테이징, 운영 서버는 validate, none

** 시스템이 자동으로 ALTER하도록 하는게 큰 사고로 이어질 수 있다.

 

 

필드와 컬럼 매핑

@Column : 컬럼 매핑

@Temporal : 날짜 타입 매핑

@Enumerated : Enum 타입 매핑

- ORDINAL, STRING -> ORDINAL은 절대 쓰지 말 것. 숫자로 저장되고 막 순서바꾸게 되면 꼬이게 됨.

@Lob : BLOB, CLOB 매핑

@Transient : 특정 필드를 컬럼에 매핑하지 않음

 

 

기본 키 매핑 어노테이션

1) 직접 할당 : @Id

2) 자동 할당 : @GeneratedValue(strategy = "요기")

    - IDENTITY : 데이터베이스에 위임, MySQL

    - SEQUENCE : 데이터베이스 시퀀스 오브젝트 사용, ORACLE

    - TABLE : 키 생성용 테이블 사용, 모든 DB

    - AUTO : 방언에 따라 자동 지정, 기본값

권장 : Long형 + 대체키 + 키 생성전략 

 

 

자동 할당 방식

IDENTITY

- DB에 들어갈 때 값이 생김.

- 영속상태가 될라면 Id값이 있어야되니까 persist() 시점에 즉시 INSERT 시행할 수 밖에 없다.

 

SEQUENCE

- @SequenceGenerator 필요

- 쭉 모았다가 쿼리 날릴 수 있다. 근데 다음 id값을 부르려면 또 쿼리를 날려야되니까 allocationSize를 활용한다.

- allocationSize 기본 50인데 이걸로 성능 조절할 수 있다. 일단 50개 갖고와서 쓸게. 

 

TABLE

- @TableGenerator 필요

 

 

 

데이터 중심 설계의 문제점

- 테이블의 외래키를 객체에 그대로 가져옴

- 객체 그래프 탐색이 불가능

- 뭔말이냐면 order 테이블에 memberId를 가지면 그 memberId를 가지고 또 member를 찾아야함. 근데 

  근데 객체 지향이면 바로 member를 찾을 수 있게 해야함. 

 

---

연관관계 매핑 기초

 

단방향 연관관계

 

객체를 테이블에 맞추어 모델링

= 참조 대신 외래 키를 그대로 사용함

객체 지향스럽지가 않다!

 

 

객체 지향 모델링은 TEAM_ID를 MEMBER테이블에 저장하는게 아니라 TEAM 객체를 바로 저장해버림

 

@ManyToOne

@OneToMany

 

 

양방향 연관관계와 연관관계의 주인

객체 연관관계는 2개 멤버>팀 , 멤버 < 팀

객체의 양방향은 사실 양방향이 아니라 서로 다른 단방향 관게 2개이다.

 

테이블 연관관계는 양방향 1개

멤버의 TEAM_ID로 바로 양쪽을 다 찾을 수 있다.

 

!!! 근데

객체 연관관계일 때, 1명의 팀을 바꿀때 멤버의 팀을 바꿀거냐, 팀에 있는 멤버를 바꿀거냐

뭐지????? 혼돈스러움!

 

그래서 나온것이 연관관계의 주인이다.

주인이 아닌 쪽은 읽기만 가능한다. 

주인은 mappedBy 속성 사용하지 않는다.

외래 키가 있는 곳을 주인으로 정해서 써야함.

결국, MEMBER가 주인이 됨. DB의 N쪽 @ManyToOne쪽!!

 

 

양방향 매핑시 가장 많이 하는 실수

- 순수 객체 상태를 고려해서 양쪽에 값을 설정하자

- 그니까 멤버에도 팀 넣어주고 팀에도 멤버 넣어주도록 고려해야함.

- 이 때, 무한루프를 조심해야함. toString 같은거.. 조심

 

양방향 매핑 정리

- 단방향 매핑만으로도 사실 이미 연관관계 매핑은 끝난 것이다.

- 단방향만 잘해두면 양방향은 필요할 때만 추가해도 된다.

- 연관관계 주인은 비지니스 로직 기준이 아닌 외래키 위치를 기준으로 정해야 함.

 

 

---

다양한 연관관계 매핑

 

다대다는 실무에서 쓰면 안된다.

 

단방향, 양방향

- 테이블은 외래키로 양쪽 조인 가능해서 방향이 없다.

- 객체는 참조용 필드가 있는 쪽으로만 참조 가능

 

다대일 [N:1]

- 다 쪽에 외래키가 가야함.

 

일대다 [1:N]

- 테이블에는 무조건 다 쪽에 외래키가 들어가야함. 무조건임.

 

---

고급 매핑

 

상속관계 매핑

@Inheritance(strategy=InheritanceType.요기 )

 

1) JOINED : 조인전략 - 각각 테이블로 변환

    - 아이템 테이블로 부모 설정, 앨범/영화/책 이런식으로 각 테이블

    - @DiscriminatorColumn(name= DTYPE)으로 타입 지정

    

2) SINGLE_TABLE : 단일 테이블 전략 - 한테이블에 전부 때려넣고 타입으로 구분

    - 성능 잘나온다.

 

3) TABLE_PER_CLASS : 구현 클래스마다 테이블 전략 - 서브타입 테이블로 변환

    - 아이템 테이블 없음.

    - DB, ORM분야 양쪽 다 비추하는 방식

    - 부모 타입으로 조회 시 여러 자식 테이블을 UNION으로 합쳐야 해서 비효율적

 

 

---

 

@MappedSuperclass

- 상속관계 매핑아님!

- 공통 매핑 정보가 필요할 때 사용

- id, name 막 여러 곳에 있을 때 상속받아서 쓴다. 근데 DB에서는 테이블에 다 있는거.

- 모든 테이블에 baseEntity응 extends로 상속해주면 된다.

 

 

 

 

---

 

 

이번 강의에선 유난히 츄르 (True)가 많이 나와서 굉장히 진지한 내용이었지만 혼자 쿡쿡대면서 볼 수 있었다.

발음 무시 X 놀리는거 X 그냥 고양이 츄르같고 뭔가 귀엽(?)달까,,

이거 츄르죠? 이거 츄릅니다~ 이게 너무 웃김 ㅠㅠㅠㅠㅠㅠ걍 취향저격임...

 

그냥 그렇다는 강의 후기,,