엔티티 매핑

 객체와 테이블 매핑

 

@Entity

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

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

 

다음은 주의할 점이다

기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자)
final 클래스, enum, interface, inner 클래스 사용X
저장할 필드에 final 사용 X

 

@Entity 속성

속성: name

• JPA에서 사용할 엔티티 이름을 지정한다.
• 기본값: 클래스 이름을 그대로 사용(예: Member)
• 같은 클래스 이름이 없으면 가급적 기본값을 사용한다.

 

@Table

@Table은 엔티티와 매핑할 테이블 지정

속성	기능	기본값
이름	매핑한 테이블 이름	엔티티 이름을 사용
목록	데이터베이스 catalog 매핑
개요	데이터베이스 schema 매핑
고유 제약 조건(DDL)	DDL 생성 시에 유니크 제약 조건 생성

 

@Table(name="MBR")

 

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

• DDL을 애플리케이션 실행 시점에 자동 생성
  • 애플리케이션 로딩 시점에 create모드로 db를 먼저 생성하고 시작할 수 있다
• 테이블 중심 → 객체 중심
  • 객체 매핑을 해놓으면 애플리케이션 뜰 때 필요한 테이블을 만들어 준다.
  • 애플리케이션이 동작하기 위해 테이블을 미리 생성할 필요가 없다.
• 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
• 이렇게 생성된 DDL은 개발 장비에서만 사용
• 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬 은 후 사용

 

관련 속성

옵션	설명
crate	기존테이블 삭제 후 다시 생성 (DROP + CREATE)
create-drop	create와 같으나 종료시점에 테이블 DROP
update	변경분만 반영(운영DB에는 사용하면 안됨)
validate	엔티티와 테이블이 정상 매핑되었는지만 확인
none	사용하지 않음

 

실습

create 모드로 변경

(좌) drop하고 테이블 생성 (우) 새로운 필드 추가시 기존 테이블 drop후 새로운 테이블 추가

애플리케이션 로딩 시점에 @Entity로 매핑된 객체를 보고 자동으로 테이블을 만든다.

만약에 create모드에서 @Entity로 지정된 객체에 새로운 필드를 추가하면 기존 테이블을 삭제하고 새로운 필드가 추가되 테이블을 새로 만든다.

 

주의할 점

운영장비에서는 절대 create, create-drop, update 를 사용하면 안된다.
테이블을 drop한 후 새로 생성되므로 누군가가 작업해 놓은 데이터가 날아갈 수 있기 때문이다.

 

권장

• 테스트 서버는 update 또는 validate
• 개발 초기 단계에는 create 또는 update
• 스테이징과 운영 서버는 validate 또는 none

 

DDL 생성기능

• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.
  
  • @Column(nullable = false, length = 10) 이런 조건은 테이블 생성할 때만 영향을 주고 런타임 시에는 영향을 주지 않는다.

 

필드와 칼럼 매핑

매핑 에노테이션 정리

에노테이션	설명
@Column	컬럼 매핑
@Temporal	날짜 타입 매핑
@Enumerated	enum 타입 매핑
@Lob	BLOB, CLOB 매핑
@Transient	특정 필드를 컬럼에 매핑하지 않음(매핑 무시)

 

 

@Column

속성	설명	기본값
name	필드와 매핑할 테이블 칼럼 이름	객체의 필드 이름
insertable, updatable	등록, 변경 가능 여부	TRUE
nullable (DDL)	null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다.
unique (DDL)	@Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약조건을 걸 때 사용한다
columnDefinition (DDL)	데이터베이스 컬럼 정보를 직접 줄 수 있다. ex) varchar(100) default ‘EMPTY'	필드의 자바 타입과 방언 정보를 사용
lenght (DDL)	문자 길이 제약조건, String 타입에만 사용한다.	255
precision, scale (DDL)	BigDecimal 타입에서 사용한다(BigInteger도 사용할 수 있다). precision은 소수점을 포함한 전체 자릿수를, scale은 소수의 자릿수다. 참고로 double, float 타입에는 적용되지 않는다. 아주 큰 숫자나 정 밀한 소수를 다루어야 할 때만 사용한다.	precision=19, scale=2

 

@Enumerated

자바 enum 타입을 매핑할 때 사용

 

속성	설명	기본값
value	EnumType.ORDINAL: enum 순서를 데이터베이스에 저장 EnumType.STRING: enum 이름을 데이터베이스에 저장	EnumType.ORDINAL

 

주의! ORDINAL 사용하면 안되는 이유

(좌) ORIDINAL (우) STRING

ROLETYPE이 enum타입으로 user, admin을 가지고 있다고 가정

EnumType.ORDINAL
A는 user이고 B는 admin이다.
ROLETYPE에 guest를 추가해서 C가 guset로 설정하면 A와 C가 구분이 안된다.

EnumType.STRING
ROLETYPE이 string으로 나와서 구분이 가능함

 

@Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용

참고: LocalDate, LocalDateTime을 사용할 때는 생략 가능(최신 하이버네이트 지원)

속성	설명
value	TemporalType.DATE: 날짜, 데이터베이스 date 타입과 매핑 (예: 2013–10–11) TemporalType.TIME: 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11) TemporalType.TIMESTAMP: 날짜와 시간, 데이터베이스 timestamp 타입과 매핑 (예: 2013–10–11 11:11:11)

LocalDate, LocalDateTime을 사용하면 @Temporal없이도 알아서 type을 맞춰준다.

 

@Lob

데이터베이스 BLOB, CLOB 타입과 매핑

@Lob에는 지정할 수 있는 속성이 없다.

매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑

• CLOB: String, char[], java.sql.CLOB
• BLOB: byte[], java.sql. BLOB

타입에 clob는 @Lob의 string을 의

 

@Transient

필드 매핑X

데이터베이스에 저장X, 조회X

주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용

@Transient
private Integer temp;

 

 

 

기본 키 매핑

기본 키 매핑 에노테이션

• @Id
• @GeneratedValue

 

직접 할당

@Id만 사용

해당 전략은 em.persist()로 Entity를 저장 하기 전, Application에서 직접 기본 키를 할당해주어야 한다.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA");

EntityManager em = emf.createEntityManager();

User user = new User();
user.setName("gillog");
user.setId(1);

em.persist(user);

 

자동 생성

@GeneratedValue + @Id

전략	설명
IDENTITY	데이터베이스에 위임
SEQUENCE	데이터베이스 시퀀스 오브젝트 사용, @SequenceGenerator 필요
TABLE	키 생성용 테이블 사용, 모든 DB에서 사용, @TableGenerator 필요
AUTO	방언에 따라 자동 지정, 기본 값

 

IDENTITY 전략

기본 키 생성을 데이터베이스에 위임

 

id에 값을 넣으면 안된다. db에 null로 insert쿼리가 날라가면 그때 값을 세팅해준다.

주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예: MySQL의 AUTO_ INCREMENT)

 

JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행하는데 AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행 한 이후에 ID 값을 알 수 있음.

 

jpa는 영속성 컨텍스트에서 관리되려면 무조건 pk값이 있어야하는데 데이터베이스에 값이 들어가기 전까지 pk값을 모르니 jpa가 관리하지 못하게 된다. (sql문은 모아서 보내는게 불가능하다)

 

따라서 IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행 하고 DB에서 식별자를 조회

tx.commit 하기 전에 insert 쿼리가 날라간다.

참고: 위 사진에 getId하는 부분에서 select 쿼리가 안나가고 바로 id값을 가져왔는데 jdbc 드라이버에 INSER쿼리를 하고나서 바로 return을 받는 내부구조가 다 짜여져 있어서 select쿼리 안날리고 member.getId()를 가져올 수 있다.

 

 

SEQUENCE 전략

데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트(예: 오라클 시퀀스)

오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용

@SequenceGenerator 필요

 

권장: id type을 Long

 

속성	설명	기본값
name	식별자 생성기 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 때 처음 1 시작하는 수를 지정한다	1
allocationSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용됨 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값 을 반드시 1로 설정해야 한다)	50
catalog, schema	데이터베이스 catalog, schema 이름

 

위 사진처럼 @SequenceGenerator 설정한 후 쿼리

 

시퀀스 전략 영속성 컨텍스트 관리 방법

em.persist할 때 db에서 값을 얻어서 member에 id 값을 넣어준다. 그 다음 영속성 컨텍스트에 넣어준다.

쿼리는 trsaction.commit()시점에 날라간다.

call next로 pk값 얻는 과정

em.persist할 때마다 call next로 pk값 얻어오는 과정에서 성능 감소에 영향을 주지 않을까?

→ allocationSize 설정

 

allocationSize 성능 최적화

https://www.inflearn.com/questions/978830

JPA는 allocationSize 만큼의 시퀀스를 미리 받아 이를 메모리에 저장. 그리고 가지고 있는 값을 모두 소진하기 전까진 메모리에서 시퀀스 값을 찾아 사용. 그리고 부족하면 다시 데이터베이스에서 시퀀스를 한 번에 받아온다.

 

만약 시퀀스를 모두 소진하기 전에 어플리케이션이 종료될 경우, 나머지 시퀀스는 사라지며 다시 사용할 수 없는 상태가 된다.. 가령 1-50번까지의 시퀀스 중 10번까지 사용하고 11-50번은 사용하지 않은 상태로 어플리케이션을 종료하고 다시 시작하면, 51번 시퀀스 부터 시작하게 된다..

 

 

TABLE 전략

키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략

@TableGenerator 필요

• 장점: 모든 데이터베이스에 적용 가능
• 단점: 성능

 

Table 전략 - 매핑

 

@TableGenerator - 속성

속성	설명	기본값
name	식별자 생성기 이름	필수
table	키 생성 테이블명	hibernate_sequences
pkColumnName	시퀀스 칼럼명	sequence_name
valueColumnNa	시퀀스 값 칼럼명	next_val
pkColumnValue	키로 사용할 값 이름	엔티티 이름
initialValue	초기 값, 마지막으로 생성된 값이 기준이다	0
allocationSize	시퀀스 한번 호출에 증가하는 수(성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema이름
uniqueConstraints (DDL)	유니크 제약 조건을 지정할 수 있다.

 

 

권장하는 식별자 전략

기본 키 제약 조건: null 아님, 유일, 변하면 안된다.

미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대 체키)를 사용하자.

예를 들어 주민등록번호도 기본 키로 적절하기 않다.

 

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