테이블 설계

사용자

• 카뎃(멘티)
• 멘토
• 보컬(스태프)

카뎃

• 인트라넷 아이디: 로그인 시 유저 데이터 검색(없으면 생성)
• 본명: 레포트 기입용, 회원가입할 때 받으므로 null 허용
• 프로필 이미지: 로그인 시 인트라 프로필 이미지 받아옴, 없을 수도 있으니 null 허용
• 이력서 링크: 본인에 대한 추가 정보를 알리고 싶은 경우 사용, null 허용
• 공통과정?: 레포트 기입용, 로그인 시 api 정보 이용 저장
• 이메일: 알림 메일 전송, 로그인 시 api 정보 이용 저장

멘토

• 인트라넷 아이디: 로그인 시 유저 데이터 검색(없으면 생성)
• 본명: 레포트 기입용, 회원가입할 때 받으므로 null 허용
• 슬랙 아이디: 인트라 아이디와 다를 수 있음, 회원가입할 때 받으므로 null 허용
• 이메일: 알림 메일 전송, 회원가입할 때 받으므로 null 허용
• 이메일: 알림 메일 전송, 회원가입할 때 받으므로 null 허용
• 회사: 레포트 기입용, 회원가입할 때 받으므로 null 허용
• 직급: 레포트 기입용, 회원가입할 때 받으므로 null 허용
• 프로필 이미지: 수정 가능, null 허용
• 멘토링 가능 상태(is_active): 회원가입할 때 받으므로 null 허용
• 가능 시간: 멘토링 가능으로 선택할 경우 기입 필요, 회원가입할 때 받으므로 null 허용
• 한줄소개(introduction): 회원가입할 때 받으므로 null 허용
• 태그: 자유롭게 작성 가능
• 마크다운 컨텐츠: 자기 소개 상세 버전

보컬

• 인트라넷 아이디: 보컬인지 확인용

기능에 필요한 테이블

• 멘토 상세 페이지에 댓글 작성 -> 댓글 테이블
• 멘토는 본인을 표현하는 키워드 선택 -> 키워드 테이블
  • 멘토 - 키워드를 묶어주는 테이블 필요
  • 키워드는 카테고리에 포함됨 -> 카테고리 테이블
  • 키워드 - 카테고리를 묶어주는 테이블 필요
• 멘토링 신청 -> 멘토링 신청 내역 테이블(mentoringLogs)
• 멘토링 후 레포트 작성 -> 레포트 테이블

기획 단계에서 테이블을 설계한 후 구현으로 넘어갔지만, 개발 중 필요한 필드가 증가하면서.. 엄청나게 많은 수정이 일어났다.
그 수정들은 귀찮은 파급효과가 있기 때문에, 기획 단계에서 최대한 신중하게 설계하는 것이 중요하다는 것을 깨달았다.

그리고 팀원마다 약간씩 의견이 달라서 가장 많은 토론이 발생한 주제이기도 했는데, 나중에 돌이켜보니 누가 맞고 틀리고의 문제가 아닌 정규화 관점이 달라서 발생한 문제였다.
또 설계할 일을 만나기 전에 정규화 관련해서 공부를 더 하고 프로젝트에 적합한 정규화 단계를 선택하고 일관성 있게 설계할 수 있도록 해야 할듯?
지금은 뭔가 아닌 느낌..
기회가 된다면 아예 다시 짜보고 싶지만 기존 데이터가 있으니 불가능하겠지...