우선 기본키 매핑은
JPA에서는 이러한 모습으로 나타난다.
이에 대한 속성과 어노테이션 등의 개념과 사용법에 대해 알아보자.
직접 할당할 떄에는 @Id만 사용하고, 이때 String으로 할 수도 있긴 하다.
이것 외에 나머지 속성들에 대해서 보겠다.
IDENTITY
IDENTITY속성은 기본키 생성을 디비에 위임하는 것이다.
@GeneratedValue(starategy = Generation.IDENTITY)로 설정해 줄 수 있고, 오라클이면 시퀀스를 생성하고 Mysql이면 Autoincrement를 생성한다.
이렇게 디비에 위임 했으면, Id값에는 null값을 넣어줘야 하고 이후 디비가 알아서 넣어주는 것이다.
SEQUENCE
@GeneratedValue(starategy = Generation.SEQUENCE)로 설정해 줄 수 있다.
디비의 시퀀스 오브젝트를 이용하여 유일한 값을 순서대로 생성한다. 이 전략은 오라클, PostgreSQL, DB2, H2등의 디비에 사용할 수 있다.
IDENTITY와는 다른 설정이 있다면, 시퀀스 생성기 어노테이션이다. name속성은 실제 @Id필드에서 참조할 이름이라고 생각하면 되고, sequenceName은 실제 디비에 생성되는 시퀀스 오브젝트의 이름이다.
그리고 시퀀스 초기값과 allocationSize라는 속성이 있는데, 여기서 allocationSize란 실제 디비에서 가져오는 시퀀스의 한번 호출에 증가하는 값의 크기이다.
시퀀스는 디비에 PK를 위임하였기 때문에, 어떤 쿼리문을 사용하던 디비에 접근하여 PK값이 몇 인지 가져와야 한다.
근데 이러한 행위를 em.persist마다 해주면 비효율적이기 때문에 allocationSize를 통해 미리 PK값을 많이 만들어 놓고, 메모리에 저장해 놓고 사용하는 것이다.
만약 서버가 꺼졌다 켜지면, 메모리에 있는 것이 날라가기 때문에 공백이 발생한다. 그래서 Size를 엄청 크게 해놓지는 않는다.
TABLE
TABLE전략은 키 생성 전용 테이블을 하나 만들어 놓고, 여기에 이름과 값으로 사용할 컬럼을 만들어 디비 시퀀스를 흉내내는 전략이다. 이것은 벤더에 의존적이지 않다고도 한다.
이 전략을 사용할 때, Auto DDL설정을 했다면 상관없지만 나중에 프로덕트 환경에서의 디비 설계에서 꼬 ㄱ시퀀스 테이블에 생성이 선행되어야 한다.
AUTO
이것은 디비 벤더에 따라 자동으로 위의 3가지 방법 중 하나를 선택해주는 것이다. 장점은 디비 벤거다 바뀌어도 코드에 수정이 없다는 것이고, 단점은 JPA엔티티 클래스만 봐도 테이블이 예쌍이 되어야 하는데 가독성이 떨어지기 때문에 추천하지는 않는다.
그래서 권장하는 식별자 전략이 뭔데?
이거는 디비를 먼저 생각을 해야 하는데, 디비의 기본 키 제약조건에 대해 먼저 생각해보는 것이 필요하다.
기본키 제약 조건은 null이면 안되고, 유일해야 하고, 변하면 안된다.
이렇게 세가지 제약 조건을 만족해야 PK로 쓸 수가 있다.
그런데 여기서 두 조건은 쉽지만, 변하면 안된다라는 조건이 쉽지가 않다.
왜냐하면 이게 정말 먼 미래까지 변하면 안되기 때문이다. 근데 이러한 조건을 만족하는 자연키(비즈니스적으로 의미있는 키. 주민번호, 전화번호 등)는 찾기 어렵다.
그래서 대체키를 사용해야 한다. 대체키는 아까 말한 GenerateValue나 랜덤 값이라던가 비즈니스와 전혀 상관없는 값을 쓰는 것을 권장한다.
그래서 권장하는 것을 요약하면
타입을 Long형으로 - 왜냐면 10억 넘어도 동작해야 하니까
대체키 - 시퀀스를 쓴다거나 등등
키 생성전략 사용 - 이러한 키 생성 전략들을 조합해서 쓰는 걸 추천한다.