문제 상황
Enum으로 되어있는 커스텀 모델 값을 새로 추가하거나 수정이 필요할 때마다 재배포가 필
이를 개선하기 위해 커스터 모델 값을 DB 테이블로 이관하여 관리하기 위해 기능 개선
enum CustomModel {
NONE("없음"),
CUSTOM1("커스텀1"),
CUSTOM2("커스텀2")
;
private String description;
public CustomModel(String description) {
this.description = description;
}
}
Java
복사
Enum으로 되어있는 커스텀 모델 값을 DB 테이블로 이관하는 작업을 수행하던 중 커스텀 모델을 사용하지 않는 경우에 대해 어떻게 처리할 지 고민 발생
1. 커스텀 모델을 적용하지 않는 채널의 경우 외래키에 null을 참조하기(외래키 속성 nullable)
2. 커스텀 모델 테이블에 NONE 레코드를 추가하여 해당 레코드의 id를 참조하기(외래키 속성 not null)
트레이드 오프
1. nullable 방식
•
장점
◦
간단하고 직관적
◦
사용하지 않는 경우에 대해 Join 없이 null을 통해 확인이 가능하여 성능상 이점이 있음
◦
효과가 미미하지만 저장 공간을 절약할 수 있음
•
단점
◦
null 처리 필요(필드 참조 시 NPE 발생 방지를 위해서 null check 필요)
◦
참조 무결성 제약조건이 약해질 수 있음
2. not null 방식
•
장점
◦
일관성을 신경쓰지 않더라도 참조 무결성을 지킬 수 있음
◦
불필요한 null 처리 없음
•
단점
◦
NONE과 같은 추가적인 레코드 필요
◦
Join 쿼리를 사용하거나 추가적인 쿼리가 발생할 수 있음
프로젝트 사항 및 비즈니스 특성 고려사항
•
커스텀 모델을 적용하는 경우보다 적용하지 않는 경우가 훨씬 많음
•
채널의 전체 레코드 수 1260 여 개(프리즘 기준)
•
현재 커스텀 모델 종류 3개(추후 증가 예정)
•
view에서 커스텀 모델에 대한 선택지가 필요한 상황이라, 전체 커스텀 모델에 대한 리스트 필요(NONE 포함)
•
채널 엔티티가 다양하고 많은 요청에서 사용됨(커스텀 모델이 필요한 경우는 많지 않음)
적용 및 결론
위의 여러 사항들을 고려했을 때 not null 방식이 적합하다고 생각됨
•
데이터 일관성 측면
◦
null을 허용하지 않아 모든 채널이 항상 커스텀 모델을 참조하고 있어 데이터 일관성(참조 무결성)을 쉽게 유지할 수 있음
•
처리 방식 일관성 유지 및 비즈니스 로직 단순화
◦
전체 커스텀 모델에 대한 리스트 제공 시 NONE을 추가하는 별도의 처리 불필요
◦
커스텀 분석 모델 적용 채널에서 커스텀 분석을 '없음'으로 변경하는 경우, 케이스를 분리하여 '없음'인 경우 null을 지정해줄 필요 없이 일괄적으로 받아온 값을 저장
◦
null 처리 불필요
•
성능 영향 미미함
◦
Channel의 수가 1260개로 비교적 적고, 채널-커스텀모델 관계가 ManyToOne 단방향 관계이기 때문에 Join에 대한 쿼리 성능이 크게 저하되지 않음
◦
커스텀 모델을 사용하지 않는 다른 요청들에 대해서는 지연 로딩으로 쿼리 수행되지 않음
•
확장성 및 개발 편의성
◦
이후 커스텀 분석을 일부분에만 적용하거나 특이한 케이스가 추가되더라도 일관적인 방식으로 처리될 수 있음
◦
null 체크를 하지 않아 커스텀 모델과 관련된 별도의 기능이 추가되더라도 null 여부에 대한 사항을 고려하지 않아도 되어 실수할 가능성이 적음