엔티티 매핑
• 객체와 테이블 매핑: @Entity, @Table
• 필드와 컬럼 매핑: @Column
• 기본 키 매핑: @Id
• 연관관계 매핑: @ManyToOne,@JoinColumn
객체와 테이블 매핑
• @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다.
• JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
• 주의
• 기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자)
• final 클래스, enum, interface, inner 클래스 사용X
• DB에 저장할 필드에 final 사용 X
@Entity
• 속성: name
• JPA에서 사용할 엔티티 이름을 지정한다.
• 기본값: 클래스 이름을 그대로 사용(예: Member)
• 같은 클래스 이름이 없으면 가급적 기본값을 사용한다.
@Table
• @Table은 엔티티와 매핑할 테이블 지정
| 속성 | 기능 | 기본값 |
| name | 매핑할 테이블 이름 | 엔티티 이름 사용 |
| catalog | 데이터베이스 catalog 매핑 | |
| schema | 데이터베이스 schema 매핑 | |
| uniqueConstraints(DDL) | DDL 생성 시에 유니크 제약 조건 생성 |
데이터베이스 스키마 자동 생성
• 애플리케이션 로딩 시점에 create문으로 db 생성하게 할 수 있음
• DDL을 애플리케이션 실행 시점에 자동 생성
• 테이블 중심 -> 객체 중심
• 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
• 이렇게 생성된 DDL은 개발 장비에서만 사용
• 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬 은 후 사용
속성
hibernate.hbm2ddl.auto
<property name="hibernate.hbm2ddl.auto" value="create" />| 옵션 | 설명 |
| create | 기존테이블 삭제 후 다시 생성 (DROP + CREATE) |
| create-drop | create와 같으나 종료시점에 테이블 DROP |
| update | 변경분만 반영(운영DB에는 사용하면 안됨) |
| validate | 엔티티와 테이블이 정상 매핑되었는지만 확인 |
| none | 사용하지 않음(주석 처리 한 것과 같음) |
주의
• 운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
• 개발 초기 단계는 create 또는 update
• 테스트 서버는 update 또는 validate
• 스테이징과 운영 서버는 validate 또는 none
=> 그냥 개발, 테스트, 스테이지, 운영 모두 안쓰는게 좋다. 써도 개발,테스트에서 validate 정도만 쓰자
- ALTER로 COLUMN을 자동으로 만들어주기 때문에 자칫하면 대장애 발생가능
- ALTER TABLE SCRIPT를 직접 적용하기 위해 개발, 테스트에서 스크립트 사용
- 다만 자동으로 스크립트를 만들어주기 때문에 운영, 스테이징에 적용할 때 스크립트를 다듬어서 적용
CREATE - 기존의 테이블 날아갈 수 있음
UPDATE - ALTER COLUMN을 통해 테이블 락이 걸릴 수 있음
가장 좋은것은 계정 분리를 통해 ALTER와 DROP을 못하게 하는것
DDL 생성 기능
• 제약조건 추가: 회원 이름은 필수, 10자 초과X
• @Column(nullable = false, length = 10)
• 유니크 제약조건 추가
• @Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})
• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.
필드와 컬럼 매핑
import javax.persistence.*;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.util.Date;
@Entity
public class Member {
@Id
private Long id;
@Column(name = "name")
private String username;
private Integer age;
@Enumerated(EnumType.STRING)
private RoleType roleType;
@Temporal(TemporalType.TIMESTAMP)
private Date createdDate;
@Temporal(TemporalType.TIMESTAMP)
private Date lastModifiedDate;
@Lob
private String description;
//Getter, Setter…
}
| 어노테이션 | 설명 |
| @Column | 컬럼 매핑 |
| @Temporal | 날짜 타입 매핑(DATE, TIME, TIMESTAMP) |
| @Enumerated | enum 타입 매핑 |
| @Lob | BLOB, CLOB 매핑 |
| @Transient | 특정 필드를 컬럼에 매핑하지 않음(매핑 무시). DB에 연동이 안되고 메모리에서만 사용하겠다는 뜻 |
@Column
| 속성 | 설명 | 기본값 |
| name | 필드와 매핑할 테이블의 컬럼 이름 | 객체의 필드 이름 |
| insertable, updatable | 등록, 변경 가능 여부 | TRUE |
| nullable(DDL) | null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다. | |
| unique(DDL) | @Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제 약조건을 걸 때 사용한다. 랜덤한 값으로 키를 생성하기 때문에 운영에서 사용할 수 없음. 보통은 @Table의 uniqueContraints를 사용 |
|
| columnDefinition (DDL) |
데이터베이스 컬럼 정보를 직접 줄 수 있다. ex) varchar(100) default ‘EMPTY' |
필드의 자바 타입과 방언 정보를 사용해 서 적절한 컬럼 타입 |
| length(DDL) | 문자 길이 제약조건, String 타입에만 사용한다. | 255 |
| precision, scale(DDL) | BigDecimal 타입에서 사용한다(BigInteger도 사용할 수 있다). precision은 소수점을 포함한 전체 자릿수를, scale은 소수의 자릿수다. 참고로 double, float 타입에는 적용되지 않는다. 아주 큰 숫자나 정밀한 소수를 다루어야 할 때만 사용한다. |
precision=19, scale=2 |
@Enumerated
자바 enum 타입을 매핑할 때 사용
주의! ORDINAL 사용X
| 속성 | 설명 | 기본값 |
| value | • EnumType.ORDINAL: enum 순서를 데이터베이스에 저장 • EnumType.STRING: enum 이름을 데이터베이스에 저장 |
EnumType.ORDINAL |
EnumType.ORDINAL은 사용하면 안된다
-> ENUM의 순서가 바뀌면 DB에는 옛날 데이터가 변경이 안되므로 에러 발생
-> 운영상에서 큰일 난다
따라서 필수로 STRING을 사용해야 됨
@Temporal
날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용
| 속성 | 설명 | 기본값 |
| value | • TemporalType.DATE: 날짜, 데이터베이스 date 타입과 매핑 (예: 2013–10–11) • TemporalType.TIME: 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11) • TemporalType.TIMESTAMP: 날짜와 시간, 데이터베이 스 timestamp 타입과 매핑(예: 2013–10–11 11:11:11) |
참고: JAVA8 시대로 오면서 필요없어졌다. LocalDate, LocalDateTime을 사용할 때는 생략 가능(최신 하이버네이트 지원) 속성 설명 기본값 value
@Lob
데이터베이스 BLOB, CLOB 타입과 매핑
• @Lob에는 지정할 수 있는 속성이 없다. •
매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
• CLOB: String, char[], java.sql.CLOB
• BLOB: byte[], java.sql. BLOB
@Transient
• 필드 매핑X
• 데이터베이스에 저장X, 조회X
• 주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용
• @Transient private Integer temp;
기본 키 매핑
• 직접 할당: @Id만 사용
• 자동 생성(@GeneratedValue)
• IDENTITY: 데이터베이스에 위임, MYSQL
• SEQUENCE: 데이터베이스 시퀀스 오브젝트 사용, ORACLE
• @SequenceGenerator 필요
• TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용
• @TableGenerator 필요
• AUTO: 방언에 따라 자동 지정, 기본값(위의 3개중 하나 선택)
IDENTITY 전략 특징
• 기본 키 생성을 데이터베이스에 위임
• 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예: MySQL의 AUTO_ INCREMENT)
• AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행 한 이후에 ID 값을 알 수 있음
• 영속성 컨텍스트의 1차 캐시를 이용하기 위해서는 ID값이 필요
• IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행 하고 DB에서 식별자를 조회
• 모아서 Insert 하는것이 IDENTITY는 불가
cf) JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
cf) JDBC 드라이버에서 자동으로 식별자를 조회하여 Select Query는 나가지 않음
SEQUENCE 전략 특징
• 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트(예: 오라클 시퀀스)
• 오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용
@SequenceGenerator
• 주의: allocationSize 기본값 = 50
@Entity
@SequenceGenerator(
name = “MEMBER_SEQ_GENERATOR",
sequenceName = “MEMBER_SEQ", //매핑할 데이터베이스 시퀀스 이름
initialValue = 1, allocationSize = 1)
public class Member {
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE,
generator = "MEMBER_SEQ_GENERATOR")
private Long id;• 시퀀스는 DB가 관리
• em.persist() 시점에 즉시 JPA에서 시퀀스로부터 값을 가져옴. 이를 이용하여 영속성 컨텍스트에 저장
• commit() 하는 시점에 insert 모두
• 성능 문제는 AllocationSize로 해결
- next call로 가져올 경우 시퀀스를 가져올 때 마다 network를 계속 사용하게 되어 성능 문제 발생
- AllocationSize를 이용하면 next call을 한번 할 때 db에 50개를 올려놓고 메모리에서는 1씩 사용
- 처음에는 next call 두번 호출
(첫번째는 1을 맞추기 위해, 두번째는 51개까지 증가시켜 메모리에서 1씩 사용할 수 있게 하기 위해)
- 그 후 50개 사용하면 next call 호출
- next call을 할때 자신이 쓸수 있는 값의 범위를 받아오기 때문에 동시성 문제 없음
TABLE 전략
• 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
• 장점: 모든 데이터베이스에 적용 가능
• 단점: 성능
권장하는 식별자 전략
• 기본 키 제약 조건: null 아님, 유일, 변하면 안된다.
• 미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대 체키)를 사용하자.
• 대체키 : GeneratedValue나 Random한 값
• 권장: Long형 + 대체키 + 키 생성전략 사용 (비즈니스 키를 사용하지 않기)
참고
