1. 데이터베이스 설계

ERD는 언제 설계하는 것이 좋을까? 프로젝트 시작과 동시에 설계하는 것이 좋음 | 모두가 공통된 데이터베이스에 대해 인지한 후 작업하는 것이 좋음

데이터베이스 설계

이름 설정

• 테이블&컬럼 이름은 모두 소문자 | 단어구분은 대소문자가 아닌 밑줄이 좋음
• 각 엔티티 정보 중 유일한 값을 기본키로 설정하기 보다 인덱스를 따로 두는 것이 편하다.
  • book_id, member_id → id
• 기본 키 타입은 int가 아닌, 추후 서비스 확장을 고려해 bigint로,,,
• create_at, updated_at에서 datatime(6)은 밀리초 소수점 6자리까지 구분한다는 의미 (MySQL은 6자리가 최대)

member(회원) 테이블의 경우, status와 inactive_date를 두는 것이 좋음

• status : 활성/비활성 상태를 나타냄 | inactive_date : 얼마 동안 비활성된 상태인지 알아내기 위함
• Hard Delete? 바로 삭제해 버리는 것... 계정 삭제 신청 후 바로 삭제되면 돌아오고 싶어도 다시 못 돌아온다,,,!!
  => 따라서, 일단 비활성화 상태로 두고 일정 기간동안 비활성인 경우 자동 삭제 되도록 설계하는 것이 좋음
• 그렇다면, 어떻게 자동으로 지울까?
  • batch? 정해진 시간에 자동으로 실행되는 프로세스... inactive된 이후 일주일이 지난 경우 삭제할 수 있도록 함 ~> soft delete

연계관계

• N:M 관계의 경우, 가운데에 매핑 테이블을 따로 둬야 함
• 해시태그의 경우, 여러 개가 한 책에 붙고, 책에 여러 해시태그가 붙음 → N:M
• 사용자가 책에 누르는 좋아요의 경우, 한 종류의 책에 여러 명의 사용자가 좋아요를 누르고, 한 사용자가 여러 책에 좋아요를 누름 → N:M

알림의 경우, 공지사항에 대한 알림은 공지사항으로, 마케팅 알림의 경우 해당 마케팅 페이지로 이동할 때 설계

• 슈퍼타입, 서브타입으로 나눠 구성 (alarm -> noitce, marketing)
• 하나의 테이블을 두고 dtype으로 구분
• 그냥 다 따로 구성(notice_alarm, marketing_alarm)

---

미션 기록

1. 테이블 정의

• user, user_mission, mission, alram 테이블 정의

 

2. 관계 정의

• 한 유저는 여러 개의 알림을 받을 수 있다. (1:N)
• 한 유저는 여러 개의 미션을 수행 수 있다. (1:N)
• 하나의 미션은 여러 사람이 수행할 수 있다. (1:N)

 

3. 요구사항 반영한 테이블 추가

• 각 지역 별로 가게들이 있으며 가게를 방문하는 미션을 해결하며 포인트를 모으는 서비스
• 모든 지역마다 10개의 미션 클리어시 1000 point 부여로 고정
• location, store, user_location_mission 테이블 추가

 

4. 관계 정의

• 한 유저는 여러 개 지역에서 미션을 수행할 수 있다. (1:N)
• 한 지역에는 여러 개의 가게가 존재할 수 있다. (1:N)
• 한 지역에 대해 여러 사용자가 진행상황을 가질 수 있다. (1:N)

 

5. 리뷰 테이블 추가

 

6. 음식 카테고리, 유저 선호 테이블 테이블 추가

 

7. 완성! (맞는지는 모르거따^^;)