1차 프로젝트에서 KinFolk를 하게 되었다.
프로젝트의 시작은 modeling이고 그만큼 탄탄하게 잘 잡아놔야 후에 고생이 없다고 들어서 modeling에 좀 더 신경 쓰려고 했다.
모델링 테이블
페이지 분석
킨포크 홈페이지를 분석해보니
STORY
오른쪽에 보이는 main_category가 있고
메인 카테고리에 들어가면 issue37, issue36 등으로 나눠진다.
우리는 그걸 sub_category로 나눴다.
또, 하나의 main_category는 여러개의 sub_category를 가지기 때문에 두 관계를 1:N으로 보았고 그래서 sub_category에 main_category라는 foreignkey를 주었다.
sub_category안에 있는 기사를 누르면
기사의 상세 페이지(스토리)가 나온다.
이 안에는 sub_category와 제목,짧은 글,긴 글,사진이 있었고 그걸 기준으로 필드를 정해주었다.
상세 페이지 안에 있는 사진은 기사마다 사진의 개수가 다르고 보통 두개 이상의 사진을 가지기 때문에 1:N관계로 보고 테이블을 따로 만들어 주었다.
또 상세 페이지의 맨 하단에는 관련 기사들을 보여주는 레이아웃이 있었기 때문에 related_stories라는 테이블도 만들었다.
이렇게 기사 관련 모델은 완성했는데 shop에 대한 부분이 제일 큰 고민이었다.
shop도 하나의 큰 카테고리니까 스토리의 카테고리와 묶어주는게 맞을지 다루는 프로덕트가 다르니까 나눠주는게 나을지 고민이 많았다.
결국 모델을 나눠서 생각하기로 결정했다.
SHOP
shop의 프로덕트가 stoty와 연결 고리가 없었고 다루는 정보 자체가 다르다고 판단되었기 때문이다.
shop페이지에 들어가면 상단에 shop에 관련한 category가 있다.
그런데 이건 story의 sub_category와 다르게 all에서 모든 데이터를 전해주고 세부 카테고리에서 filter를 돌려서 전해주면 된다고 판단해서 굳이 sub_category로 나누지 않았다.
제품의 상세 페이지에는 사진과 제품 이름,가격,설명과 shipping 관련 콘텐츠가 있다. 그걸 프로덕트의 필드로 나누어주었다.
또한 스토리와 마찬가지로 여러장의 사진(1:N)과 연관 제품이 있어서 related 관계의 테이블을 만들어주었다.
USER-ORDER-CART
휴 대망의 user,order,cart...,
몇 번을 수정했는지 모르겠다.
처음엔 quantity도 product 테이블에 있었는데
멘토님과 얘기를 하다보니 수량에 관련된건 order에 있으면 되는 부분이고 cart가 order와 product를 연결해주는 테이블이니 cart로 빼기로 했다.
중간 테이블 개념인 cart에는 product_id와 order_id를 가진다.
user 테이블에는 user가 로그인을 할 때 필요한 이메일과 비밀번호를 가지고
user 정보가(token)이 있어야 주문 가능한 order는 user를 foreignkey로 가지고 주문을 위한 정보들을 가진다.
또한 주문의 상태(주문 전, 주문 완료, 배송 ... )을 가져야 하기 때문에 order_status 테이블을 만들고 order에 foreign키를 주어 연결했다.
