[JPA] 테이블 Entity 매핑과 필드 매핑 유의사항

@Entity 사용 유의사항  

1. @Entity를 매핑해서 사용할 클래스는 기본생성자는 필수다(public 또는 protected 생성자)

JPA 구현체들은 클래스의 인스턴스를 생성할 때 기본 생성자를 필요로 한다. 기본 생성자가 없으면 JPA 구현체가 클래스의 인스턴스를 생성할 수 없다. 또한 JPA는 성능 최적화를 위해 프록시 패턴을 사용하는데 프록시 객체를 생성하는데 기본 생성자가 필요하다.

 

2. Final 클래스, enum, interface, inner 클래스에는 사용할 수 없다.

Final 클래스는 상속이 안되므로 프록시 객체를 생성하지 못한다.

 

3. DB에 저장할 필드에 final을 사용하면 안된다.

JPA는 엔티티를 영속성 컨텍스트에서 관리하고 데이터베이스와 상호 작용할 때 필드의 값을 변경할 수 있어야 한다. final필드를 사용하면 객체가 만들어 짐과 동시에 값이 세팅되고 변경이 불가능 하므로 JPA 로직과 맞지 않다.

 

@Enumerated 사용 유의사항

옵션으로 무조건 EnumType.STRING을 써야한다.

@Enumerated의 기본값은 EnumType.ORDINAL인데 ORDINAL은 enum 순서를 데이터베이스에 저장하는 것이고 STRING은 이름을 데이터베이스에 저장하는 것이다.

 

EnumType.ORDINAL을 사용하면서 문제점은 Enum 클래스에 값을 추가할 때 생긴다.

기존에 RoleType Enum 클래스에 USER, ADMIN만 있었다고 했을때 EnumType.ORDINAL로 사용하면 DB에는 USER는 0, ADMIN는 1로 저장되었을 것이다.

하지만 아래처럼 RoleType Enum 클래스에 GUEST를 맨 앞에 추가하면 GUEST가 0으로 바뀌면서 기존 데이터 USER 데이터도 0이기 때문에 혼돈이 생긴다. 

EnumType.STRING을 쓰면 DB에 값이 GUEST, USER, ADMIN 그대로 들어가기 때문에 혼돈이 생기지 않는다.

 

스키마 자동 생성 기능 종류와 유의사항

아래 hibernate.hbm2ddl.auto 속성에서 운영 DB에는 validate, none만 사용해야 한다.

보통 개발 초기 단계는 create, update를 사용하고 테스트 서버는 update, validate를 사용 스테이징과 운영서버는 validate, none을 사용한다. 

update가 문제가 되는 이유는 테이블 컬럼이 추가될때 테이블 락이 걸리기 때문이다. 데이터가 클수록 락 시간이 길어지는데 5분정도만 락 걸려도 시스템에 큰 장애가 생기는 것이기 때문에 운영때는 사용하면 안된다.

 

테이블 유니크 제약 조건 유의사항

유니크 제약조건은 @Colum이 아닌 @Table에 사용해야 한다. @Colum에 하게되면 유니크키 이름이 랜덤으로 나오는데 딱 보고 어떤 필드의 조합인지 식별이 안된다. 그래서 @Table에 사용하여 유니크 키의 이름을 지정하도록 한다.

 

 

@Table에 유니크 제약조건 추가 방법