기능 기획이 끝났다면 이제 백엔드 설계가 필요하다.
DB 모델링이 필요한 데 아래 샘플을 보면 여러 방법으로 데이터 표현이 가능하다.
그 전에 어떤 DB를 사용할 지 결정하여야한다. DB 는 관계형 DB 와 NoSQL(비관계형DB)가 있는데 각각 장단점이 있어서 서비스 마다 어떤 DB 를 사용할 지 고민이 필요하다. 내가 만드는 프로젝트에서 사용하는 데이터들이 간단한 모델로 가능하고 각 데이터 간의 관계가 복잡하지않다면 NoSQL인 MongoDB 써서 빠르게 개발하는 것도 좋다. 그러나 유저, 댓글, 상품1, 상품2 등 데이터 간의 관계가 복잡하다면 mySQL 같은 RDB(관계형DB)를 쓰는 것을 추천한다.
짜-잔! 우리 팀의 백엔드 개발자인 승현👨🏻💻이 그린 초안에 팀의 토론과 합의에 의해서 탄생한 최종 DB 모델링이다.
먼저 데이터의 성격은 이렇다.
users - 사용자 정보 테이블
cards - 크로스핏 용어 카드 정보 테이블
quiz_answers - 사용자가 각 퀴즈를 맞춘 정보 테이블(해당 퀴즈를 맞았는지 틀렸는지 정보를 담는다)
comments - 댓글 정보 테이블
quizzes - 크로스핏 용어 맞추기 퀴즈 정보 테이블
categorys - 크로스핏 용어의 카테고리 정보 테이블
각 데이터 간의 정보는 화살표(점선)으로 표현했다. 사실 더 정확히 관계도를 파악하면 점선인지 실선인지 1:1 관계인지 1:다 관계인지 고민이 많이 필요한 데, 4주 만에 프로젝트 개발을 끝내야하는 시간의 자원이 제한있는 우리들이므로 개발을 위한 설계 정도만 해도 충분하다고 생각한다.
데이터 모델링을 할 때 조심해야하는 것은 각 테이블에 있는 id 가 유니크 값인지 통일성있는 규칙(단수 복수 처리 등)으로 설계 도안을 만들었는지 등을 꼼꼼히 볼 필요가 있다.