앱 제작 과정 (6) 백엔드 - seed data 만들면서 DB 설계 오류 발견하기

만들면서도 테이블 수정할것들이 생겼다.가령, Like 테이블을 왜 만들었는지?;; 나, category_id, tab_name이 겹치는데 그대로 있었다는 것

 

아래는 시드파일로 데이터 넣는걸 작업한 순서대로의 보충설명들이고, 작업하는 과정마다 수정이나 생각해봐야할 부분들이 있었다.

• Categories DB - tab_name 필드가 category_name 필드와 기능이 겹치게 설계되어있어 삭제했고, 원래 존재하는 카테고리 네 개를 데이터로 넣었다.
• Challenges DB - 챌린지 종류를 10개 만들었다. 챌린지 보상(소행성 이름, 소행성 사진) 관련 데이터도 다 있음.
• Users DB - ChallengeImages seed 데이터 하려고 보니까 각 챌린지에 유저가 중복 참여도 가능하고, 나중에 챌린지용 뷰에서 참여중인 유저들을 보여주는 UI/UX를 넣을 때 데이터가 적으면 작업이 잘 안될 것 같아서 기존 4명말고 추가로 50여명을 넣었다.
• ChallengeImages DB - 각 챌린지에 참여하는 유저 수를 적절히 조정하여 10명 이내, 인기 있는 챌린지는 25명 정도로 참여로 저장했다.
• ChallengeMembers DB - ChallengeImages 테이블에 존재하는 각 데이터마다 대응되는 ChallengeMembers seed 데이터를 저장.
  맹점 발견: Challenges 테이블에 각 챌린지마다 챌린지 진행 기간이 다른데(1주/2주 등), 그 정보를 갖고 있는 필드가 없다는것...!! 사람마다 챌린지 참여 날짜가 다 상이할 수 있으니, 챌린지 진행 날짜는 절대적인 날짜가 아니라 상대적인 날짜로 설계하다보니 테이블 필드를 구상할 때 빼먹었다. 
• Reports DB
• Rewards DB - 이것이 필요한 이유가 잘 기억이 안나는데 유저가 설정에서 달성한 챌린지 봤을때 그거 보여주려고 만든거였나..? 근데 그게 없다.

+ 

• Categories DB 
• Likes DB - Posts DB에 like 필드를 추가해주고, 댓글의 like는 그냥 프론트에서 구현해주면 될 것 같아서 아예 DB를 삭제하기로 했다.
  근데 그러면 의문점... 그 댓글마다의 Like 수치 자체는 어떻게 어디로 저장하는거지..?..
• ChallengeMembes DB - 처음에 ChallengeParticipation DB -> ChallengeMembers DB로 바꿨는데, 다시 ChallengeParticipation이 직관적이라 네이밍에 나을 것 같다. 그 이유는 아래와 같이 reported 정보나, status 정보도 가지고 있기 때문에.
  
  

 

---

 

이를 위키에 총정리를 해보았다.

 

https://github.com/est22/Asteroid_App/wiki/DB-수정사항

DB 수정사항

 

하면서 사이드바도 추가..