@Id 만 사용한다.
@Id
와 @GeneratedValue
를 사용한다.
IDENTITY
: DB에 위임, MYSQLSEQUENCE
: DB 시퀀스 오브젝트 사용, ORACLE@SequenceGenerator
필요
TABLE
: 키 생성용 테이블 사용, 모든 DB에서 사용 가능하다@TableGenerator
필요
AUTO
: 방언에 따라 자동 지정, 기본값
: 기본 키 생성을 DB에 위임한다.
- MySQL, PostagreSQL, SQL Server, H2DB 에서 사용
MySQL은 AUTO_INCREMENT
- AUTO_INCREMENT는 DB
INSERT
SQL을 실행한 이후 ID값을 알 수 있다. em.persis()
시점에 즉시INSERT
SQL 실행하고 DB에서 식별자 조회한다.즉,
INSERT
SQL을 실행할 때까지 기본키 값을 확인할 수 없다.
: DB 시퀀스 오브젝트 사용한다.
- 아이디 값을 임의로 넣으면 안 된다.
- 영속성 컨텍스트에 값을 저장할 때
DB sequence
에서 기본키 값을 가져온다.insert
쿼리는 날아가지 않는다.
속성
속성 | 설명 | 기본값 |
---|---|---|
name |
식별자 생성기 이름 | 필수 |
sequenceName |
DB에 등록되어 있는 시퀀스 이름 | hibernate_sequence |
initialValue |
DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 떄 처음 1 시작하는 수를 지정한다. | 1 |
allocationSize |
시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용, DB 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야한다.) | 50 |
catalog , schema |
DB catalog , schema 이름 |
예시
@Entity
@SequenceGenerator(
name = "MEMBER_SEQ_GENERATOR",
sequenceName = "MEMBER_SEQ",
initialValue = 1, allocationSize = 1)
public class Member {
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE,
generator = "MEMBER_SEQ_GENERTOR")
privat Long id;
}
: 키 생성 전용 테이블을 하나 만들어서 DB 시퀀스를 흉내 내는 전략
- 모든 DB에 적용 가능하나 성능이 않좋다.
그냥 사용잘 안 한다. 알아만 두자
create table MY_SEQUENCES (
sequence_name varcar(255) not null,
next_val bigint,
primary key ( sequence_name )
)
@Entity
@TableGenerator(
name = "MEMBER_SEQ_GENERATOR",
table = "MY_SEQUENCES",
pkColumnValue = "MEMBER_SEQ", allocationSize = 1)
public class Member {
@Id
@GeneratedValue(strategy = GenerationType.TABLE,
generator = "MEMBER_SEQ_GENERATOR")
private Long id;
}
@TalbeGenerator - 속성
속성 | 설명 | 기본값 |
---|---|---|
name |
식별자 생성기 이름 | 필수 |
table |
키생성 테이블명 | hibernate_sequences |
pkColumnNmae |
시퀀스 컬럼명 | sequence_name |
valueColumnNa |
시퀀스 값 컬럼명 | next_val |
pkColumnValue |
키로 사용할 값 이름 | 엔티티 이름 |
initialValue |
초기 값, 마지막으로 생성된 값이 기준이다 | 0 |
allocationSize |
시퀀스 한 번 호출에 증가하는 수(성능 최적화에 사용됨) | 50 |
catalog , schema |
DB catalog , schema 이름 |
|
uniqueConstraints (DDL ) |
유니크 제약 조건을 지정할 수 있다. |
- 기본 키 제약 조건
null
이 아니다.- 유일해야 한다.
- 불변해야 한다.(엄청 어렵다)
- 대체키를 사용한다.(미래까지 이 조건을 만족하는 자연키는 찾기 어렵다)
- 권장: Long형(10억이 넘어도 동작) + 대체키 + 키 생성전략
실무 경험 공유
- 주민등록번호를 기본 키로 쓰고 있었다.
- 나라에서 "주민등록번호를 보관하면 안 된다"라고 정책이 바뀌었다.
- 문제는 기본키 가 아니라 기본키를 사용하는 외래키로 주민번호를 가지고 있을 것이다.
- 마이그래이션을 진행할 때 엄청 난리 났다.
- 만약 대체키를 사용했으면 주민등록번호 테이블을 지우거나 다른 테이블로 대체했으면 됬었다.