DB 리팩토링을 진행하자

개요

레시피 저장소 리팩토링을 진행하면서 DB 구조에도 변경이 필요하다고 느꼈다.
기존과 달라진 기능들도 일부 생겼고, 기존 DB에 불필요하게 중복돼서 저장되고 있는 데이터들도 있었다.
기존 DB에 국한해서 생각하다보니까 아예 기존 DB에 한계가 지어진 채로 생각하게 된 것 같아서 아예 새롭게 DB를 구성한다고 생각하고 재설계를 해보기로 했다.

요구사항

회원	레시피	냉장고	냉장고바구니	재료
카카오 로그인	유튜브 레시피 검색	냉장고 조회	냉장고 바구니 조회	재료 조회
네이버 로그인	블로그 레시피 검색	냉장고 추가	냉장고 바구니 조회	재료 추가
구글 로그인	공공 레시피 검색	냉장고 수정	냉장고 바구니 수정
회원가입	추천 레시피 조회	냉장고 삭제	냉장고 바구니 삭제
로그아웃	나의 레시피 작성
회원탈퇴	나의 레시피 조회
회원 프로필 조회	나의 레시피 수정
회원 프로필 수정	나의 레시피 삭제
	인기 검색어 목록 조회
	자동 검색어 목록 조회

테이블 구성

1차 예비테이블 구성

• 요구사항 정의에 따라 대략적으로 어떤 테이블이 필요할지 1차 정리했다.

• 원래 삭제 시에 테이블 내 데이터 상태를 수정하다가 DB 유료 사용을 하면서 데이터 용량을 줄이려고 삭제하기로 결정했었다. 무료로 다시 바꾸면서 다시 상태 변경하고 쌓아도 되긴 하지만 이미 삭제로 결정했던 상황에서 그렇게 유지할 이유가 없어서 이번엔 상태 컬럼을 아예 넣지 않았다.

• 유튜브와 블로그에 레시피 검색한 결과를 저장하는 테이블을 추가했다. API 호출 제한 문제를 이렇게 한 번 해결해보려고 했다. 그리고 url을 통해서 해당 주소로 이동하는 구조고 따로 앱 내 정보가 아니라서 기본적 레시피 테이블과는 분리가 필요했다.

• 공공 레시피와 나의 레시피는 비슷한 형식으로 구성하기로 했어서 우선은 분리했던 테이블을 합치기로 했다. 이렇게 형식을 동일하게 가져가면서 공개/비공개를 할 수 있게 해서 레시피 검색 데이터를 좀 더 풍부하게 할 수 있게 하려고 했다.

• 냉장고, 냉장고 바구니 테이블은 단위 컬럼을 추가하기로 했다.

• 재료는 직접 입력한 재료를 추가할 수 있게 하려고 해서 등록한 사람 컬럼도 추가했다.

• 각 테이블에 id 컬럼을 따로 추가하고 PK로 하기로 했다.

중복 데이터 제거

• 재료 카테고리는 동일한 정보가 재료마다 반복적으로 나타나게 된다. 그래서 재료 카테고리 정보를 저장하는 재표 카테고리 테이블을 추가하기로 했다.

다중값 제거

• 조회수와 스크랩수 같은 경우에는 회원 고유번호와 매핑하는 매핑 테이블을 추가하기로 했다.

• 한 레시피마다 여러 레시피 과정이 존재한다. 그래서 레시피의 요리 과정에 대한 정보는 다중값에 해당하므로 테이블을 따로 빼주었다.

• 한 레시피마다 여러 레시피 재료가 존재한다. 그래서 레시피의 재료들에 대한 정보 또한 다중값에 해당하므로 따로 테이블을 빼주었다. 그리고 각 정보들을 따로 저장하는 것이 아니라 재료 테이블과 연결하여 저장하도록 하여 중복 데이터를 가지지 않도록 하려고 했다.

• 가입 SNS 아이디 값에 가입 SNS 종류를 붙여서 저장하고 있으므로 따로 저장하지는 않기로 했다.

필요 테이블 추가

• 탈퇴 시 이유를 입력받는 기능이 들어가면서 탈퇴 이유를 저장하는 테이블을 추가했다.

• 인기 검색어 조회를 위해 검색어 관련 테이블이 추가될 필요가 있었다.

필드 명세 설정

• PK id값을 int unsigned로 하기로 했다. uuid보다 성능이 좋고 예약번호 같이 외부에 노출될 값이 아니므로 그냥 int auto increment로 사용해도 무리가 없을 것 같았다.

• 정의 테이블로 관리하는 게 좋을지, ENUM으로 관리하는게 좋을지는 항상 고민이 되는 것 같다.

  • 재료 카테고리와 탈퇴 이유 코드는 우선 크게 변경이 되지 않을 것 같긴 하지만 변경 가능성도 있고 참조 테이블로 관리해보기로 했다.

  • 대신 냉장고/냉장고 바구니의 단위, 레시피 난이도 등은 ENUM으로 관리하려고 한다.

관계 설정

완성된 ERD

• 기존과는 달리 블로그, 유튜브 레시피 정보를 테이블에 따로 저장하기로 해서 이에 따라 블로그, 유튜브 레시피 스크랩 테이블에는 따로 url, 썸네일 등의 정보를 저장할 필요가 없어졌다. 그냥 해당 아이디 값을 저장하면 되게 돼서 더 깔끔해진 느낌이 있다.

• 직접 입력한 재료들을 재료 테이블에 저장하도록 하면서 냉장고, 냉장고 바구니 테이블에서 해당 재료를 참조하기만 해도 돼서 중복 데이터가 줄어서 좋은 것 같다. 추가된 재료를 매번 냉장고에 재료 정보를 전부 저장했던 부분이 개선된 것 같다.

• 나의 레시피와 공공 레시피 구조를 통합하게 되면 테이블을 하나로 활용할 수 있어서 좋은 것 같다. 제공하는 정보에도 좀 더 통일성이 있을 수 있을 것 같다.

• 레시피 재료들도 재료 테이블을 참조하게 되면서 재료를 각각 저장하고 있는 것보다 중복 데이터를 줄일 수 있을 것 같다.

기타

• 푸시 알림 정보에 대한 컬럼 추가가 필요할 듯 하다. 이건 정의가 된 이후에 추가해야겠다.

참고: https://velog.io/@sontulip/how-to-db-design