[DB] VER2 설계에 대한 고민
- 배경
명식이 ver2로 업데이트를 함에 따라 확장 기능을 고려한 ERD 설계를 하려 합니다. ver1 서비스는 단순 학식 메뉴를 조회하는 기능 위주의 서비스를 제공하고 있었기 때문에 학식에 대한 테이블만 존재했습니다. ver2에는 리뷰 남기기와 학식에 대한 맛 평가, 학교 근처 맛집 리스트를 저장해서 모아 보는 찜꽁 리스트 기능이 도입 됩니다. 이에 ERD 설계를 아래와 같이 진행하려 합니다.
- 고민 Point
- 사용자 테이블을 만들 것인가
현재 명식이는 회원가입의 프로세스가 존재하지 않습니다. 기존 명식이를 이용하던 유저들에게 회원가입을 통한 개인 정보를 요구해야 하는 가에 대한 고민이 있었습니다. 회원가입과 로그인 프로세스를 거치지 않고 사용자 기기 고유 식별 번호를 통해 유저를 등록하는 식의 플로우를 통해 유저를 단순히 식별할 수 있는 정보만을 받는 것으로 결정하였습니다.
- 자바에서 enum으로 사용되는 데이터를 공통코드 테이블로 관리할 것인가
enum 값으로 사용되는 모든 데이터들이 가장 큰 고민이었습니다. 기획의 변경 혹은 예기치 못한 이유로 enum에서 사용되는 값들은 변경될 수 있습니다. enum으로 사용되는 값들이 많다면, 이를 하나의 테이블로 관리하는 것이 좀 더 효율적이지 않을까 하는 생각이 들었습니다. 이는 DB 중심의 설계에서 관리의 편의성을 가져다 줄 수는 있습니다. 하지만 어플리케이션 중심으로 바라볼 때, 공통코드 테이블과 비즈니스 엔티티 간의 직접적인 연관관계를 맺는 것은 오히려 복잡도를 높일 수 있다는 생각이 들었습니다. 현재 프로젝트에서 사용 중인 Spring Data JPA 기술을 고려했을 때에도 공통코드 테이블을 별도로 두었을 때의 비즈니스 로직보다 ENUM으로 사용하는 것이 로직이 더 깔끔하게 작성될 거 같다판단했습니다.
따라서 enum으로 사용되는 데이터들은 공통코드 테이블로 관리하는 것이 아닌 지금처럼 enum으로써 문자열로 DB에 저장하기로 하였습니다.
-
공통 코드 테이블 포함_설계
-
ENUM 사용_설계
-
참고 사이트