당근마켓 ER Diagram(1차 수정)

---

관련해서 멘토분의 피드백을 받게 되었고 이를 근거로 몇 가지를 수정하였다.

📌 도움 주신 멘토분 피드백

1. 테이블명 축약 및 자잘한 변수명 수정

1) 어차피 테이블임을 알고 있으므로 테이블명 끝 Table 문구 삭제
2) 변수명 조금 수정 (특히나 FK로 사용되는 부분은 변수명 최대한 통일)
3) 테이블명 수정 (모아보기 테이블 -> Follow)
4) 데이터의 예상 용량에 따른 속성 수정(Varchar 크기 수정 등. ex.메시지)

2. 테이블 병합 / 삭제

• EmotionListTable
  (어차피 그리 많지 않음, 상태코드를 통해 리스트처럼 사용 가능)
• CategoryTable
  (위와 동일한 사유)
• BuyHistoryTable과 SellHistoryTable 합체 -> TransactionTable 생성
  (속성이 거의 비슷하여 상태코드를 따로 만들어 분리 가능)

3. 변수 위치 조정 및 삭제

• UserTable 내 매너온도, 재거래희망율, 응답률 항목 제거
  -> 쿼리문을 통해 파악하는 걸로 결정
  • • 재거래희망율:
      구매자가 남긴 후기(good or bad)를 뜻하는 속성 제작 후 이를 조회
  • • 응답률:
      채팅 답장 횟수(구매자(buyerId)가 제작한 채팅방 내 채팅에서 fromid가 판매자(sellerId)인 채팅이 있는지의 유무를 조회
  • • 매너온도:
      위 2가지를 합산하는 공식을 만들어 매너온도 제작)
      
• 동네인증횟수를 사용자 동네(User Region) 테이블에서 사
  용자(User) 테이블의 속성으로 이전
  -> 마찬가지로 동네 테이블과 inner join 통해 계산해서 저장 고려
  (근데 이는 구현이 상당히 복잡할 것 같다.. 생각을 조금 더 해봐야할 문제)
  

4. 채팅 관련 테이블 추가

• 단순 채팅이 아닌 사진 보내기 기능 및 일정 및 약속 위치 지정 기능 추가
  고려 테이블 제작 (사진 데이터 테이블(1대n), 일정 관련 데이터 테이블(1대1))

느낀 점

생각해볼만한 점이 많은 피드백이었다.
보통 속성으로 리스트는 구현하기 어려우므로 다 테이블로 빼서 그 pk id를 불러오는 방향을 생각했었다.
그런데 피드백을 듣고 생각해보니 bit(0/1)마다 존재/비존재의 여부를 가르듯이,
해당 상태코드를 단순 문자 혹은 숫자로 만들어 분류가 가능할 것이라는 아이디어를 떠올렸다.

그 외에도 pk 코드 unsigned int (PK로 음수는 쓸 일이 없고 자동 증가이므로) 팁, 데이터 용량 팁 등등을 확인할 수 있었다.

근데 ERD를 어느정도 끝내고 나니.. 쿼리문이 문제이다 ㅋㅋ;
일단 구현해볼 화면을 빠르게 3개 선정하고(채팅, 일반 게시판, 유저 정보)
쿼리문을 작업하고 있다.

p.s 피드백 주신 디유님 감사드립니다..

링크
z0nj8r