1조 ERD 실습

1조

ERD 설계 - 브레인 스토밍

사용자

• 회원 : 판매자, 구매자 (Role Enum)→ 권한으로 구분 vs 테이블로 분리
  • 판매자 / 구매자 기능이 완전히 분리되어 있으므로, 일단 테이블로 분리하도록 진행
  • 예를들어 판매자는 사업자 정보를 등록할 수도 있어야하고, 정책사항, 매장 ID 등을 갖고있을 수 있다

전시

• 매장
• 음식
• 쿠폰
• 쿠폰 정책
• 회원 - 쿠폰 연결 테이블
• 발급 날짜
• 사용 여부
• 결제
• 회원 ID
• 주문 ID
• 결제 상태 (결제요청, 결제중, 결제완료, 결제취소)
  • 하나의 레코드에서 컬럼을 수정하는 방식으로 관리하지 않고, 각각을 레코드로 관리한다고 한다.
  • 결제는 민감한 정보이니, 로그성으로 남기는듯하다.
    • 고민할 부분: 이렇게 설계할 때 인덱싱 적용이 적절할까? (잦은 create)
• 생성,수정,삭제 날짜
• 중복 결제 요청을 어떻게 막아야할까
  • 애플리케이션 레벨에서 멱등성 키를 발급하여 관리한다
  • 테이블로 들어갈 값은 아님
• 주문
• 회원 ID
• 매장 ID
• 상품 ID
• 개수
• 고민해야할 부분: 동일 매장의 상품인지 validate

생각해봐야할 부분

1. 옵션같은 비정규형 데이터를 RDB 정규화로 관리하는게 좋을까?

• 일반적으로 옵션은 사장 마음대로 커스터마이징할 수 있음
• 음식 옵션 선택 → RDB 정규화로 관리하기 까다로울 수 있겠다.
• 방법1. 옵션 컬럼 + JSON
• 방법2. NoSQL

2. 쿠폰 선착순 문제

• 발급 기준으로 할 것인가?
• 결제 기준으로 할 것인가?

3. 정산 테이블

• 일반적인 커머스 플랫폼은 모든 수익을 가져가고, 정산일에 정산한다고 함. → 정산 테이블