최근 현행DB를 재설계 하면서 드는 고민 중 하나가 유저의 속성 중 단순 분류가 가능한, 비교적 정적인 데이터(직업, 학력 등)를 어떻게 관리할 것인지입니다.

이전에는 클라이언트 측에 분류되어있는 직업이나 학력의 문자열 데이터를 그대로 저장했습니다만, 이럴 경우 분류에 조금이라도 변경이 이루어진다면 해당 문자열을 전부 update하는 문제가 있었습니다.

대안으로 생각한 방법은 아래 두 방법입니다.

1. 직업, 학력 테이블을 생성하여 유저 테이블과 일대일 관계를 맺음.

2. 백엔드 코드에 id private 변수를 갖는 ENUM 클래스를 만들어 유저 테이블에 ENUM id값을 저장.

1번 대안의 경우 join이 발생하지만, Primary key로 한 건씩만 join되고, 직업이나 학력 분류의 경우 아주 적은 데이터가 들어가기 때문에 join을 하더라도 성능상 이슈가 크게 생길 것 같지는 않습니다.

하지만 2번 대안이 나온 이유는 직업이나 학력 분류는 아주 적고 ENUM 값과 id값이 매핑되어있어 이를 사용하면 비즈니스 로직 상 특정 학력이나 직업의 id값을 사용해야할 때 일관성 있게 코드를 짤 수 있기 때문입니다. 현재 공통 코드 테이블이 없어 status값의 경우 이렇게 처리하고 있습니다.

경험이 적어 항상 선택의 기로에 서는데 이 문제는 많이 발생하는 케이스인 것 같아 꼭 해결하고 싶어서 질문 드립니다.