객체와 테이블 매핑 : @Entity, @Table
필드와 컬럼 매핑 : @Column
기본 키 매핑 : @Id
연관관계 매핑 : @ManyToOne,@JoinColumn
객체와 테이블 매핑 : @Entity, @Table
@Entity가 붙은 클래스는 JPA가 관리하는 엔티티- JPA를 사용해서 테이블과 매핑할 클래스는
@Entity필수 - 주의
- 기본 생성자 필수 (파라미터가 없는 public 또는 protected 생성자)
- final 클래스, enum, interface, inner 클래스 사용X
- 저장할 필드에 final 사용 X
@Table엔티티와 매핑할 테이블 지정
데이터베이스 스키마 자동 생성
- JPA는 애플리케이션 실행 시점에 DB 테이블을 생성하는 기능 제공
- 테이블 중심 -> 객체 중심
- 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
- 이렇게 생성된 DDL은 개발 장비에서만 사용 > 운영서버에는 사용 X, 필요한 경우에는 적절히 다듬은 후에 사용
속성
create기존테이블 삭제 후 다시 생성 (DROP + CREATE)create-dropcreate와 같으나 종료시점에 테이블 DROP, 보통 테스트를 할 때 사용update변경분만 반영 (운영DB에는 사용하면 안됨), 추가하는것만 가능하고 지우는건 안됨validate엔티티와 테이블이 정상 매핑되었는지만 확인none이 기능을 사용하지 않겠다
주의
- 운영 장비에는 절대 create, create-drop, update 사용하면 안됨
- 개발 초기 단계는 create 또는 update 권장
- 테스트 서버는 update 또는 validate (create를 하면 데이터 다 날라감)
- 스테이징과 운영 서버는 validate 또는 none
- 테스트 서버나 개발 서버에도 본인이 직접 스크립트를 짜서 문제 없으면 적용하는 것이 좋음!!!
- 로컬PC에서만 자유롭게 하고 여러명이 사용하는 개발서버나 운영서버에는 가급적 사용하지 않는다 > 자동으로 생성되는걸 참고해서 좀 다듬어서 사용하거나.. 하는것이 좋음
필드와 컬럼 매핑 : @Column
@Column: 컬럼 매핑- name : 필드와 매핑할 테이블의 컬럼 이름, 데이터베이스의 컬럼 명 설정
- nullable(DDL) : null 값의 허용 여부를 설정, false로 설정하면 DDL 생성 시에 not null 제약조건이 붙음
- length(DDL) : 문자 길이 제약조건, String 타입에만 사용
- columnDefinition(DDL) : 데이터베이스 컬럼 정보를 직접 줄 수 있음, 쓴것 그대로 반영됨
@Enumerated: enum 타입 매핑- EnumType.ORDINAL : enum 순서를 데이터베이스에 저장
- EnumType.STRING : enum 이름을 데이터베이스에 저장
- default는 ORDINAL
- 무조건 EnumType.STRING를 사용!!!!
- enum 타입의 데이터 순서가 바뀔수도 있으니 ORDINAL은 절대 사용 XX
@Temporal: 날짜 타입 매핑- LocalDate, LocalDateTime을 사용할 때는 생략 가능 (최신 하이버네이트 지원)
- TemporalType.DATE : 날짜
- TemporalType.TIME : 시간
- TemporalType.TIMESTAMP : 날짜와 시간
@Lob: BLOB, CLOB 매핑- 큰 컨텐츠를 넣고싶을 때
- 매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
@Transient: 특정 필드를 컬럼에 매핑하지 않음 (매핑 무시)- DB와 관계 없이 메모리에서만 사용 하겠다
- 필드 매핑X, 데이터베이스에 저장X, 조회X
기본 키 매핑 : @Id
기본 키 매핑 어노테이션
- @Id
- @GeneratedValue
기본 키 매핑 방법
- 내가 직접 ID를 만들어서 할당 : @Id 만 사용
- 값을 자동 생성해서 할당 : @GeneratedValue 사용
@GeneratedValue(strategy = ) 전략
- default는 AUTO
- AUTO : DB 방언에 맞춰서 자동으로 생성
- IDENTITY : 기본 키 생성을 데이터베이스에 위임
- IDENTITY 전략은 DB에 넣어봐야 PK 값을 알 수 있음
- 하지만 영속성 컨텍스트 1차 캐시에 PK 값이 저장 되어있어야 함
- 보통은 commit 하는 시점에 INSERT 쿼리가 날라가지만, IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회
- 모아서 commit 시점에 insert 하는 것이 IDENTITY 전략에서는 불가능 (단점)
- SEQUENCE : 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트, Long 타입을 사용하는 것이 좋음
- SEQUENCE 전략이면 em.persist() 시점에 DB 테이블에서 다음 값을 얻어와 객체에 Id 값을 저장후 영속성 컨텍스트에 저장
- 실제 트랜잭션 커밋 시점에 insert 쿼리 호출
- TABLE : 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략, 모든 데이터베이스에 적용 가능한 장점이 있으나 성능이 좋지 않음
권장하는 식별자 전략
- 기본 키 제약 조건 : null 아님, 유일, 변하면 안됨
- 비즈니스를 키로 끌고오는것은 권장하지 않음
- 권장 : Long형 + 대체키 + 키 생성전략 사용
getter는 다 만들어도 상관 없지만
setter는 가급적 생성자에서 다 세팅을 하고, setter의 사용을 최소한으로 하는 것이 좋음
