무지성 DB 모델링

meetup 프로젝트를 시작하면서 가장 먼저 한 것은 구현할 서비스에 대한 DB 모델링이었다. 일단 브레인스토밍 하듯 필요할 것 같은 객체에 대해 나열하고, 동작할 것 같은 방식으로 관계 맺고, 이를 기준으로 엔티티 파일 생성했다.

모임이니까 당연히 유저와 모임 룸은 필요하다고 판단했다. 이것을 중심으로 유저는 업로드사진 테이블이 필요하다고 생각했다. 유저와 모임은 다대다 관계가 될 수 있으니 참여유저, 호스트유저, 리뷰, 호스트의 리뷰 작성 을 조인테이블로 만들었다. 모임 룸은 카테고리 테이블과 다대일로 관계를 만들었고 업로드파일 및 업로드 이미지 테이블들과는 일대일 관계를 만들었다. 유저의 경우 관리자 기능을 위해 공지사항 테이블과 일대다 관계를 맺고 공지사항 테이블은 이미지와 업로드파일 각 테이블과 일대일 관계를 맺었다. 모든 테이블에서 공통으로 쓰일 생성과 수정 시간에 대한 정보는 BaseEntity로 만들고 모든 테이블에서 상속받아서 구현했다.

만들면서 몇몇 의문이 떠올랐다. 유저와 룸 사이 조인테이블을 굳이 4개씩 만들 필요가 있으며, 특히 호스트 유저 테이블과 호스트유저의 댓글 테이블이 꼭 필요할까? 정규화에 어긋나는데 데이터 관리 및 보기 편할 것 같은 이유로 유저, 공지사항, 룸에 각각 업로드 내지는 이미지 테이블을 1:1로 각각 만들어줄 필요 있을까? 등 테이블 간 관계에서 각 테이블의 필요에 대한 정당성에 의문이 들었다. 설계의 기준을 적용할 수 있더라면 했겠지만 역량이 부족했다. 일단은 학습 위한 기능구현에 집중했다.

전반적으로 기능하는 프로젝트 만들고나서 다시 기존의 DB 모델링 결과를 둘러보니 무지성으로 DB 모델링 했던 기억이 떠올라 불편하다. 개선하고 싶은데 어떤 방식으로 하면 좋을지 고민중이다. 그 중 생각 및 적용해볼 만한 한가지 기준에 대해 알 수 있는 글 읽었다. 42 동료가 쓴 "42체크인 DB 설계 – 정규화와 역정규화 (https://42place.innovationacademy.kr/archives/9463) " 이 글이다.

DB 모델링 수정 기준 1 - 정규화와 역정규화

글 요약해보니 42 서울 체크인 시스템 클론코딩하면서 DB 모델링 시행착오 공유 내용이었다. 인상 깊은 내용은 다음과 같다. 무의식으로 항상 정규화하고, 객체구조와 DB 테이블 관계를 일치시켰지만, 핵심은 효율적인 문제해결이고 정규화와 역정규화는 문제해결의 과정일 뿐이라는 내용이 기억 남는다.

이 내용을 토대로 무지성으로 모델링한 테이블 구조를 살피니 다음 스탭이 보인다. 먼저는 해결하고자하는 문제가 무엇이고, 그것을 해결하기위해 빼도 될만한 부분은 어디인지 찾아봐야겠다. 그 부분을 발견한다면 역정규화는 당연히 될거고 객체와의 관계는 깨져도 괜찮겠다.

그렇지만 이 기준 말고도 여러 기준이 더 필요 할 것 같다.

다른 DB 모델링 기준은 ...

일단은 더 이것저것 알아봐야겠다.