JPA 엔티티 매핑

 

JPA는 데이터베이스 스키마를 자동으로 생성하는 기능을 지원한다.

클래스의 매핑 정보를 보면 어떤 테이블에 어떤 컬럼을 사용하는지 알 수 있다. JPA는 이 매핑정보와 데이터베이스 방언을 사용해서 데이터베이스 스키마를 생성한다. 

 

목차

 

💡 유니크 제약 조건

---

@Table(
    name="테이블 이름",
    
    uniqueConstraints={
        @UniqueConstraint(
             name = "unique 제약조건 이름",
             columnNames = {
                "포함할 컬럼이름 1",
                "포함할 컬럼이름 2"
            }
      ),
}

유니크 제약 조건은 단지 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다. 

그래도 이 기능을 사용하면 애플리케이션 개발자가 엔티티만 보고도 손쉽게 다양한 제약 조건을 파악할 수 있다는 장점이 있다.     

 

💡 IDENTITY 전략

---

• IDENTITY는 기본 키 생성을 데이터베이스에 위임하는 전략이다. 
• IDENTITY  전략은 데이터를 데이터베이스에 INSERT한 후에 기본 키 값을 조회할 수 있다. 따라서 엔티티에 식별자 값을 할당하려면 JPA는 추가로 데이터베이스를 조회해야 한다. 
  • 엔티티가 영속 상태가 되려면 식별자가 반드시 필요하다. 그런데 IDENTITY 식별자 생성 전략은 엔티티를 데이터베이스에 저장해야 식별자를 구할 수 있으므로 em.persist()를 호출하는 즉시 INSERT SQL이 데이터 베이스에 전달된다. 따라서 이 전략은 트랜잭션을 지원하는 쓰기 지연이 동작하지 않는다.(트랜잭션 커밋 전에 데이터베이스에 바로 저장되어야 하는 특성 때문이다.) 
    *쓰기 지연 : 여러개 의 엔티티가 영속성 컨텍스트에 추가되고 변경된 내용이 한꺼번에 데이터베이스에 반영되는 것을 의미한다.  

💡 @Enumberated

---

✅ EnumType.ORDINAL 

• EnumType.ORDINAL : enum 순서를 데이터베이스에 저장
  • enum에 정의된 순서대로 ADMIN은 0, USER는 1값을 데이터베이스에 저장한다.
  • 데이터베이스에 저장되는 데이터 크기가 작지만, enum의 순서를 변경할 수 없다.

✅ EnumType.STRING 

• EnumType.STRING :  enum 이름을 데이터베이스에 저장 
  • 이름 그대로 ADMIN은 ADMIN, USER는 USER라는 문자로 데이터베이스에 저장된다.
  • 저장된 순서가 바뀌거나 추가되어도 안전하지만, 데이터베이스에 저장되는 데이터 크기가 ORDINAL에 비해서 크다. 

💡ORDINAL은 주의해서 사용해야 한다.
ADMIN(0번),USER(1번) 사이에 enum이 하나 추가돼서 ADMIN(0번),NEW(1번), USER(2)로 설정되었다.
이제부터 UsER는 2로 저장되지만 기존에 데이터베이스에 저장된 값은 여전히 1로 남아 있다. 
따라서 이런 문제가 발생하지 않는 EnumType.STRING을 권장한다.