[DB] VER1 설계에 대한 고찰 , 오류 인정, 개선 방향
명식이라는 앱을 런칭하기로 마음을 먹고 프로젝트를 시작한다. 그 당시에 무엇보다도 속도이었다. 단순히 MCC식당의 메뉴를 보기위한 앱이길 원해 시작하였다. 처음에는 출시의 속도가 최우선이었기에 수동배포로 진행하다 수동배포의 번거로움으로 인해 CICD를 구축하였다. 그 정도로 출시와 많은 것들이 Trade off가 이루어졌다.
- 과한 정규화
원래는 Week, Food로 이루어진 테이블 단 2개의 DB구성이었다. 왜냐면 단순히 식단 메뉴를 보기 위한 그 이상 이하도 생각하지 않았다. 하지만, 사용자들의 요구사항으로 주변식당과 자연캠퍼스에 대해서 고려하지않았다. 과한 정규화의 시점은 출시 2일전에 기존의 중식, 석식에서 중식의 타입이 A,B로 나뉘어지는 문제가 발생했다. 여기서 내가 생각한 것은 Food에 Type의 컬럼을 추가하는 것이 아닌 Lunch와 Dinner로 나눴다. 그 이유는 중식에 대해서만 타입이 주어지고 석식에는 존재하지 않기 때문에 타입이 추가된다면 석식에는 null이 존재하는데 그렇게 된다면 하루에 3개의 로우가 생기는데 3분의 1이 null인 공간이 생기기 때문에 Food -> Lunch, Dinner로 정규화를 하였다.
당시 메뉴판
<기존>
<변경후>
- Enum 클래스 미고려
위의 과한 정규화를 Enum클래스로 관리했더라면 매핑관련해서도 최적의 조회속도를 낼 수 있었으리라 생각한다.
- Lunch와 Dinner를 합친 테이블 생성
ver2를 준비하면서 자연 캠퍼스의 식당에도 서비스를 제공하는 것으로 결정되고 테이블 설계를 다시하면서 다시 식단 메뉴에 대해서 하나의 테이블에서 관리하기로 하였다. 기존의 가졌던 나뉘어진 것을 Enum클래스로 관리하여 값들을 관리하고자 한다.
