[데이터베이스] 팀별 미니 프로젝트(2) - 의류 쇼핑몰 ERD 그리기

https://docs.google.com/document/d/1FixTkViw9zbUrnbYrKfecxjvh4DvCrCdj3VDTT8KLy0/edit?usp=sharing

ERD CHECKLIST

(위 링크는 발표 대본 요약)

 

팀별 과제: 

1 의류 쇼핑몰에 대한 테이블 설계

  회원과 비회원에 대한 구분 필요 (서비스 등)

  의류는 계절별 상의로 하며, 기타 세부사항은 팀별 자율적으로 결정함.

  단, 결제는 모두 마일리지(현금) 으로만 처리하는 것으로 함. (마일리지 부족 시 카카오페이지로 충전)

진행 방식: 팀별로 전체적인 테이블 구성 회의 후, 각자 그리기.

 

진행 과정

0. 시장조사

참고 리스트: 무신사, shein, cider, 쿠팡, 지그재그, 네이버 스마트스토어

 

1. 툴 선택

여러가지 툴을 한번씩 사용해보다가 결국에는 비주얼 스튜디오에서 제공하는 ERD.EDIT을 사용하기로 했다. 사유는 무료 툴임에도 광고가 붙지 않고, (ZOOM 으로 발표해야 했기 때문에) 40%로 축소했을 때 테이블명과 릴레이션이 한 눈에 보이는 (아래 사진과 같은) 기능이 전체적인 로직을 설명하는 데에 적합하다고 생각했기 때문

다만, 번역된 툴 사용 관련된 블로그도 별로 없고, FK가 표시되지 않아 고생함. (간단한 오류이거나, 이번 업데이트의 문제인 듯 하다. 그렇게 생각한 이유는, SQL 코드로 들어가면 정상적으로 FK가 표시되는데, 전체 표로 보면 FK가 표시되지 않음 더불어 중간에 한 번 렉걸려서 다운됨... 노트북 문제인지 프로그램 불안정성 문제인지는 잘 모르겠음. 저장할 것. )

 MSI 에서 만들어서인지 키들이 익숙했기 때문했음.

---

 

2. 팀원들과 회의를 통해 쇼핑몰의 전제 만들기 

1. 회원 / 비회원 테이블

근본적으로 비회원은 쇼핑몰 사용이 불가함. 비회원 역시 SNS 연동을 통해서 전화번호를 받는 것으로 간주하고, 전화번호를 PK로 설정해, 회원가입 없이 SNS 연동만 한 회원의 경우 임시 아이디, 비밀번호 발급을 하는 것으로 처리. 

한 쪽 성별에 관련된 쇼핑몰이라고 전제하고, 회원 정보에서 성별을 뺌. 

(이렇게 하면 남자 옷을 파는 쇼핑몰이라고 해도, 성별에 관계 없이 옷을 구매)

회원에 주소가 있기는 하지만 NULL 이 가능하도록 하고, 따로 배송지 테이블을 만듦. 

2.  마일리지

이전달 마일리지 사용 총액을 토대로 회원 등급을 나누고 등급에 따라 쿠폰이나 포인트가 적립되도록 만듦. 이렇게 적립된 쿠폰이나 포인트는 결제 시 사용할 수 있도록 함. (다른 팀원들은 쿠폰으로 하고, 나는 포인트로 함)

3. 상품

각 상품에 색상, 원단, 소매 길이 등의 특징을 넣어 자유롭게 묶거나 찢을 수 있도록 함. 더불어, 사용자가 체크박스 특징 선택만으로 자신이 정확하게 원하는 상품에 도달할 수 있도록 함.

 ex. "핑크색 긴팔 니트가 필요함" <핑크> / <긴팔> / <니트소재> 선택

4. 기타

옵션 / 장바구니 / 찜 테이블 만들기

환불테이블 만들기

게시판 카테고리 만들어서 게시판마다 num 붙여주고, 관리자 따로 테이블 만들어 공지/ 문의 답변/ 상품 업로드 등 특정 게시판에는 관리자 번호를 반드시 들어가도록 함.

---

  3. 테이블 설계하기. 

 

<결과>

 

1. 전체 테이블 구조. 

전체적인 구조 (사용 툴 : 비주얼 스튜디오의 erd editor)

방점을 두었던 점은 중복되는 데이터가 없도록 만드는 것. 

예를 들어, 회원 테이블은 처음 생성되고 개인정보를 변경하는 경우 외에는 업데이트되지 않도록 배송지, 마일리지, 등급 등 모두 다 뺐다. 

2. 각 테이블 구조

(탈퇴/정지 여부는 한 컬럼으로 처리할 수 있을 듯)

앞서 말했듯 전화번호 pk, 주소 우편번호는 null 가능

 

마일리지 기록은 한 달에 한 번 업데이트됨. 한달 총 결제금액과 이를 통한 회원 등급 산출. 이 등급으로 마일리지 테이블에 있는 포인트 적립. 포인트는 사용때마다 변동되므로 마일리지 테이블에 넣음. 

마일리지는 사실상 결제 테이블임. 결제하거나 충전하거나 환불받을 때 업데이트 됨. 카카오페이로 충전하려면 토큰? 도 필요하다는데... 잘모르겠음... 

처음에는 한 테이블로 정리했다가, 불필요하게 업데이트가 자주 된다는 생각이 들어서 (당연함... 결제테이블이 없었으니까) 마일리지를 따로 뺌. 

환불 테이블. 결제가 마일리지로만 이루어지기 때문에, 환불도 마일리지로만 이루어짐. 

환불 종류 코드는 환불/ 교환/ 주문취소를 나누는 코드. 교환할 경우 주문한 상품 중 상세 옵션이나 내용이 필요하기 때문에 주문 상세 테이블과 릴레이션을 줌. 

앞서 언급한 주문 상세 테이블과 배송지 테이블, 그리고 상품과 상품 옵션. 

상품당 조회수가 없는 이유는 상품 업로드게시판이 따로 있기 때문. (원가도 이와 같은 맥락에서 이해 가능. 판매가는 상품 업로드 게시판에 올라감. ) 

관리자와 게시판 카테고리. 

관리자가 복수인 경우라고 전제함. 

관리자 아이디가 필수인 세 가지 게시판들. (모두 게시판 카테고리 넘버가 fk로 들어간다)

상품 업로드 게시판에는 최신순 정렬, 인기순 정렬을 위해 조회수와 date를 넣음 .(지금 생각해보니 리뷰순 정렬도 많이들 하는데 리뷰 개수도 넣을 걸 그랬음...)

 

마지막으로 회원이 사용하는 게시판 테이블들. 

---

느낀 점 (다른 팀 발표 들으면서 내 ERD에서 아쉬웠던 점, 명확하게 틀렸다고 생각되는 점들.)

1. 이미지 처리

가장 큰 문제. 옷 파는 쇼핑몰에서 이미지가 빠진 게 어이가 없음... 상세페이지는 어떻게 보여줄건지?

참고로 이미지는 blob가 아니고 주소 varchar 로 해야...

2. 환불/교환/주문취소

다른 팀 보니까 각각 다른 테이블로 뺐는데, 나는 환불 테이블 안에서 환불 코드 컬럼으로 구분했다. 생각해보면 특히 교환은 환불과 로직도 진행도 결과도 다른데 한 테이블로 처리한 건 잘못된 것 같다. 

3. 찜과 장바구니

이건 관찰의 실패...

지그재그만 봐도 알 수 있는데 찜에는 수량이 들어가면 안되고, 장바구니에는 수량이 들어가야 한다. 이게 찜과 장바구니의 가장 큰 차인데 난 둘 다 무의식으로 수량 컬럼을 넣음. 비효율적일 뿐더러 그냥 틀린 것. 

4. 결제

이건 정답을 모르겠음.

난 결제 테이블이 없음 결제 할 때마다 변동되는 마일리지만 있을 뿐.. 

그럼 적어도 마일리지 코드가 주문 코드에 들어갔어야 하는 것은 아닌지

5. 이외에 자잘한 실수들

여러번 검토했다고 생각했는데 자잘한 실수가 있었음. 중복해서 들어간 컬럼도 하나 있었고. 당연히 다 넣었다고 생각했던 등록일도 문의 게시판에서 빠져 있었다. 

 

테이블 설계부터 기능과 로직에 관한 고민이 들어가야 하는구나... 이후로도 계속 수정이 들어갈 수도 있다는 생각을 함. 아직 입문 2개월차기도 하고, 짤 시간도 하루밖에 없었어서 부족한 점이 많지만 재밌는 것 같긴 함