ERD 작성

구현 목표는 회원가입과 로그인, 카테고리별 상품 목록, 상품별 상세, 장바구니 기능이다.
구현하고자 하는 기능에 따라 필요한 테이블을 만들고 관계를 설정하는 방식으로 진행했다.
주문, 배송 관련 테이블은 ERD만 작성해보았으며 추후 더 고민해보자.

카테고리별 상품 목록

• main과 sub 카테고리의 수가 많지 않아서 정규화하지 않고 한 테이블에 넣으려고 했었다. 데이터의 볼륨이 적어서 이렇게 테이블을 줄이는게 나을거라 생각했다.
  -> 테이블 정규화가 가장 기본이라는 피드백을 받았다. 테이블 관계가 명확하고 언제든지 추가 및 확장될 수 있다는 것을 고려해야 한다.

• 세트 상품도 하나의 product로 관리하기로 했으며 이에 따라 scent 테이블과 다대다 테이블로 구성하였다.

• product의 name은 고유하지 않다. product name과 collection name이 합쳐졌을때 비로소 고유한 product가 된다.
  -> 하나의 collection은 여러개의 product를 가질 수 있다.
  

상품별 상세

• 상품 사이즈는 여러 단위 (g,ml,oz)가 존재하며 모든 단위를 가지고 있진 않다. (null 가능)
  -> 컬럼을 3개로 나눠서 단위별로 데이터를 관리하기로 했다.

• 상품 목록에 나오는 설명과 상세페이지에 나오는 설명을 구분하기 위해 description과 detail_description으로 나누었다.

• product마다 고유의 thumbnail 이미지가 있으며, 상세페이지에는 중복되는 이미지를 사용하기도 한다. thumbnail 이미지만 따로 product 테이블에 넣으려 했으나 모든 이미지를 한 테이블로 관리하고자 is_thumbnail 컬럼을 만들었다.
  -> 원래는 다대다 테이블로 만드는게 맞지만 중복되는 사진이 얼마없는 만큼 일대다 관계로 진행하기로 했다.

장바구니

• option은 모든 상품에 적용되는 메시지 카드 선택이었기 때문에 product가 아닌 cart 테이블에 연결했다.

• 한 유저는 product와 option 조합에 따라 여러개의 cart를 가질 수 있다고 생각했다.
  -> cart items 테이블을 따로 만드는 방법도 있었다.

• ERD 작성시 생각해볼점
  Work flow chart를 먼저 작성해본다면?
  테이블 관계시 식별, 비식별 등도 구분해야하나?
  상품과 서비스에 대한 정확한 분석을 하고 시작했다면?
  데이터별 조회하는 빈도수와 흐름을 고려했다면?

---

Django app과 models.py

잦은 수정으로 인한 마이그레이션 충돌을 방지하기 위해 신중히 진행했다.
다행히 일부 옵션 및 필드만 수정을 해서 큰 문제는 없었다.

아래는 models.py에서 일부 생략된 코드이다.

users app

• 유니크 속성과 선택 정보 속성을 적용했다.

• Django 컨벤션은 문자열 필드는 null 값이 아닌 빈문자열로 표현한다고 한다. (birthday는 날짜 필드라서 null 가능)

products app

• 다음엔 on_delete 말고 다른 외래키 옵션도 사용해보고 싶다.

• soft delete를 위해 is_deleted 필드를 추가했다.

• 다대다 필드를 만들때 scent에 manytomany 키를 넣었다. 향에 따라 상품 목록을 보여줄때 접근을 편하게 하기 위함이었다. 다만, 상품 상세에서 상품에 따른 scent 정보를 가져올때는 역참조 형태가 된다.
  -> 무엇이 더 나은지 고민해봐야 한다.

cart app

• orders 앱에서 장바구니 기능까지 구현이 가능할지 고민했지만, 우선 app을 나누어 진행했다.

• quantity의 기본값을 0으로 하라는 피드백을 받았는데, 추후 장바구니 CRUD를 구현할때 그 이유를 깨달았다.
  -> 이미 추가된 상품은 수량만 증가하도록 작동해야하는데, get_or_create 를 사용하기 위해 반드시 필요한 옵션이었다.

core app - TimestampModel

• 모든 테이블에는 이력관리를 위해 작성일시와 수정일시 필드가 필요하다.

• 공통으로 적용되는 필드는 추상화 모델을 만들어 상속한다.
  
  
  

• models.py 작성하며 생각해 볼점
  ManytoMany 필드는 어디 테이블에 넣을까? 어느 테이블 정보가 메인인가?
  외래키의 다른 옵션에는 무엇이 있고 언제 필요할까?
  이력관리 외에 추상화 모델을 사용하는 경우는 언제일까?
  default 값을 고정할 수도 있지만 positive integer 등 여러 옵션을 적극적으로 사용한다면?

---

DB에 데이터 입력

• Mac의 numbers 테이블에 데이터를 넣고 csv 파일로 전환했다.

• db_uploader.py를 만들어 csv 파일 정보를 DB에 저장했다
  -> print()로 바꾸고 django shell에서 실행해보면 어떤 데이터가 선택된건지 어렵지 않게 이해할 수 있었다.

• 로컬에서 numbers로 만드는 것보다 구글 스프레드 시트 등으로 공동 작업이 가능한 환경을 만들었어야 한다.
  -> 팀원들과 공유하기 쉽게해야겠다.
  

• 내용 수정은 MySQL workbench, Table Plus 툴을 사용했다.

• 데이터를 넣으며 생각해볼 점
  프론트 엔드에 넘겨줄 데이터의 타입은?
  상세 페이지 정보는 HTML tag까지 통채로 넣어주기?
  tag까지 복사하는 경우 이스케이프 문자가 포함되어 버린다면?

---

모델링과 DB 작업을 하며 느낀점

• DB 설계를 위해선 서비스와 상품를 잘 이해하고 있어야 하며, 이는 곧 비지니스 로직을 이해하는 것이다.

• DB 설계는 혼자하는게 아니다.
  개발자뿐 아니라 다양한 내부 사람들과 대화 (유저 친화적, 운영 친화적)

• 유저 경험뿐 아니라 어드민 경험도 중요하다.
  MD, 재고관리, 배송업체 등 다양한 이해관계자가 필요로 하는 데이터를 보관하고 관리해야 한다. -> 마케팅 통계 분석을 위한 데이터까지.
  

• 처음엔 데이터를 보관할 공간을 고려했다면 이후엔 데이터의 쓰임에 대한 고민을 하게 되었다.
  이는 곧 DB와 서버 성능 최적화와 관련이 있을 것이다.

• 아쉬운건 처음에 유저의 흐름이 아닌 사이트 기능 구현에만 집중해서 큰 그림을 보지 못한것이다.
  유저의 패턴을 이해하고 상품 구성을 이해하는 것을 우선시 할껄.

• 처음부터 프론트엔드와 적극적으로 소통하면서 어떤 데이터 타입을 넘겨주어야 할지 정해야 한다.
  나중에 계속된 DB 수정은 개발의 속도를 늦출 수 있다.