음식점 검색 기능
https://github.com/choisooyoung-dev/d-ingco.git
GitHub - yujin0708/sparta_b5: 스파르타 B5조 팀 프로젝트
https://excalidraw.com/#room=6fb17da070ce495cb68d,AcVe0YmxIg2pTMm59zYpyw
1. 팀원들간 존중하며 소통하기
2. 모르는 것 있으면 서로 공유하기!
3. T발언 하지 않기
1. 완성하기
2. 강의 다 듣기
3. 본인이 맡은 파트 책임지고 완성해보기
오전 회의: 10시
오후 회의: 7시
* 2. 기획 관련 메모와 3. WBS & Tasks가 중복되어서 있네요. 하나는 삭제해주시면 됩니다!
* 와이어프레임이 아주 명쾌하게 잘 작성이 되어있습니다! 화살표까지 세세하게 그려주셔서 어떤 플로우인지 직관적으로 이해가 되네요.
* 다만, 가능하다면 가입 시 node-mailer와 같은 패키지를 이용해서 이메일 인증을 하는 것이 좋겠습니다.
* 이렇게 한다면 적어도 유저 정보 변경시에 이메일을 변경할 일은 없을테니까요.
* 와이어프레임 상에서 사장님이 업장 메뉴를 추가하는 것은 가능한데 수정, 삭제를 하진 못하네요. 이것도 고려해주셔야 합니다.
* API 명세서에서 토큰은 Bearer 토큰으로 넘겨주세요!
* 메뉴 생성 및 수정시에 이미지 URL을 넘기는 이유는 뭘까요? 이미지 파일을 업로드해주셔야 됩니다.
* 이미지 파일을 업로드하기 위해서는 Content-Type이 multipart/form-data여야 합니다.
* 리뷰는 주문과 매칭이 되어야 합니다.
* 즉, 주문 A - 리뷰 C, 주문 B - 리뷰 D와 같이 페어링이 되어야 합니다.
* 하지만, 지금의 경우에는 어떤 주문인지와는 관계 없이 그냥 리뷰를 달 수 있는 구조입니다.
* 리뷰 조회를 제외한 생성, 삭제, 수정에 대한 API 명세를 POST /orders/:orderId/reviews처럼 주문 밑에 리뷰가 위치하게끔 해주세요.
* 이와는 별개로, 전체 리뷰 조회는 GET /restaurants/:restaurantId/reviews로 하시면 됩니다.
* 특정 음식점에 대한 전체적인 평가를 보여주는 데 적합하며 사용자가 특정 음식점의 리뷰를 한눈에 볼 수 있게 하기 때문이죠.
* ERD 피드백
* 리뷰는 오더와 1:1 관계가 되어야 합니다.
* 오더는 여러개의 메뉴를 포함할 수 있어야 합니다.
* 지금처럼 설계가 되면 한 사람이 하나의 메뉴만 시키는 경우밖에 커버를 못하게 됩니다.
* 오더_디테일과 같은 테이블을 새로 생성하여 오더 ID, 메뉴 ID를 FK로 삼는 테이블을 만들어야 될 것입니다.
* 혹은, 오더안에 details와 같은 컬럼을 넣고 JSON으로 관리하는 것도 방법입니다.
* 메뉴는 레스토랑과 N:1의 관계가 되어야겠죠?
* 사용자와 사장님은 하나의 users 테이블로 합치고 사장님의 경우에는 별도의 restraunts 테이블에 업장 정보를 등록하게끔 하는게 좋습니다.
* users 테이블로 합칠 때 role로 사용자 혹은 사장님을 구분하면 문제가 없습니다.