[투표] JPA Enum 처리 방식 결정 (제어 레벨 및 저장 타입)

[mainlib990]

안녕하세요, 팀원 여러분.

JPA에서 Enum 값을 데이터베이스에 저장하는 방식은 데이터의 무결성, 가독성, 성능 및 유지보수성에 큰 영향을 미칩니다. 특히 Enum 값의 유효성 검증을 Application 레벨에서 할 것인지, DB 레벨에서 할 것인지를 기준으로, 각 제어 레벨 내에서 숫자 또는 문자열 중 어떤 형태로 저장할 것인지를 비교하여 팀의 표준을 정하고자 합니다.

---

📝 안건 1: Application Level에서 제어

• 설명: 데이터베이스는 Enum 값을 일반적인 숫자나 문자열로 저장하며, Enum 값의 유효성 검증 및 비즈니스 로직은 애플리케이션 코드에서 담당합니다.

  1-1. 숫자로 저장 (@Enumerated(EnumType.ORDINAL))

  • 설명: Java Enum의 ordinal() 값(순서)을 INTEGER 타입 컬럼에 저장합니다.
  • 장점: 공간 효율성, 성능.
  • 단점: 매우 취약함 (Enum 순서 변경 시 데이터 손상 위험), DB 가독성 저하.

  1-2. 문자로 저장 (@Enumerated(EnumType.STRING))

  • 설명: Java Enum의 name() 값을 VARCHAR 타입 컬럼에 저장합니다.
  • 장점: DB에서 값 확인 용이, 구현 단순.
  • 단점: DB 레벨 무결성 검증 부족, Enum 이름 변경 시 마이그레이션 필요.

---

📝 안건 2: DB Level에서 제어

• 설명: 데이터베이스 자체가 Enum 값의 유효성을 검증하고 관리합니다.

  2-1. 숫자로 저장 (별도의 테이블(ID)로 관리)

  • 설명: Enum 값을 관리하는 별도의 테이블을 생성하고, 메인 엔티티에서는 이 테이블의 ID(숫자)를 외래 키로 참조합니다.
  • 장점: 강력한 DB 무결성, DB 가독성(별도 테이블 참조), 확장성.
  • 단점: JOIN 연산으로 인한 성능 영향, 스키마 및 매핑 복잡성.

  2-2. 문자로 저장 (Postgres 전용 Enum 타입 사용)

  • 설명: PostgreSQL에 CREATE TYPE으로 Enum 타입을 정의하고, 엔티티 컬럼을 이 전용 Enum 타입으로 매핑합니다.
  • 장점: 강력한 DB 무결성, 가독성 및 효율성, DB 기능 활용.
  • 단점: DB 종속성, JPA 매핑 복잡성, 스키마 변경 관리.

---

📝 안건 3: 기타 유연한 제어 방식

3-1. AttributeConverter를 활용한 커스텀 매핑

• 설명: JPA AttributeConverter 인터페이스를 구현하여 Java Enum과 DB 컬럼 타입 간의 매핑 로직을 직접 정의합니다. Enum의 특정 필드(예: code 값)를 저장하는 등 매우 유연한 처리가 가능합니다.
• 장점: 높은 유연성, Enum의 내부 값(code 등)을 DB에 저장 가능, DB 타입에 대한 완전한 제어.
• 단점: 구현 복잡성 증가, 커스텀 로직에 대한 테스트 필요.

---

🗣️ 중점 논의사항

각 방식은 데이터 무결성, 가독성, 성능, 그리고 유지보수성 측면에서 명확한 장단점을 가집니다. 특히 @Enumerated(EnumType.ORDINAL) 방식은 그 취약성 때문에 일반적으로 권장되지 않습니다. 우리 프로젝트의 특성과 중요도를 고려하여 최적의 방안을 선택해 주시기 바랍니다.

[SeoGyeongWon]

Application level과 DB level에서 제어는 취향차이라고 생각합니다.
성능측에서는 Application level에서 처리하는것이 좋다고 알고있고, 안전성 측면에서는 DB에서 처리하는것이 좋다고 알고있습니다.
Application level에서 충돌이 발생하면 문제가 커지는데, 저희의 프로젝트 규모가 작은편이여서 그렇게 충돌이 발생할 일이 없다고 생각합니다.

그래서 Application level에서 처리하며, Enum에 들어갈 값들이 적었기에 문자로 저장을해도 공간효율성에 크게 영향을 미치지 않을것 같습니다. 그렇기에 2번을 골랐습니다

[kimdotcom2]

저희가 이미 엔티티를 설계하면서 DB 단에서 참조 무결성을 검증하는 대신, 애플리케이션 단에서 검증 로직으로 무결성을 체크하도록 합의된 바가 있으니, 통일성을 위해 애플리케이션 레벨에서 일관적으로 검증하는 것이 좋다고 생각합니다.

그리고 다른 분들의 코드도 보았는데 Enum 이름은 코드잇에서 제공한 값을 따르고 있고, 마이그레이션 가능성은 없다고 판단하여 2번을 지지합니다.