Project 2- 2일차 (4): [erd 모델링] 각자 작성 후 다같이 수정 및 리뷰

[진행 방식]

1. pk, fk 협의  

(pk 빼고는 다 fk) 

 

2. 화살표 어떻게 갈지

최대한 완벽하게 설계해도 결국엔 수정할 게 나와서
일단 넘어가도 됨

수요일 오전 dbmate 만들고
목금, mvp 하고 (추가 기능은 현진님) 
사실상 1주로 끝. 
2주째에는 통신만

데이터베이스는 일단 다 해놓고, 프론트와 나중에 협희 후 빼기로 

---

[팀 논의]

user table에 주소를 넣을지 ? 

 user:주소 = 1:1 (유저가 하나의 주소 , 주소가 한개만 가능하고) 로 생각했는데

 

다른 사람에게 주문하는 경우 고려해서 1: 다  로 수정

 

 

user table

email, passowrd, nickname, 전화번호 , profile image, 제공자 (소셜로그인- 네이버 같은 거) 

 

email, id 는 unique 값

 

프로필 이미지, 닉네임은 null (리뷰 기능에만 필요한데, 혹시 구현할 수 있으니, null 로 넣은 거) 

 

order table 

'주문자 정보/ 받는 사람 정보' 구분 

주문 테이블에 들어가야 함, 배송 테이블이 아니라 -> 이름 (내 이름일 때만 가져올 수 있으니)                          

 

ordername _ null (주문자와 받는 사람이 다를 경우 쓰는 경우니, 같은 경우 

 

 

ordername product - 상세페이지, 메인페이지 합쳐서 --> 

상세페이지의 정보가 다 product table에서 오는게 아니라 다 다르게 오는 거라

 

 

 

<흐름>

구두는 option에 색상 안 해도 되는 --> 구두라 단조로워서 

 

혹시 같은 상품에 색상 여러개로 빼서 Product 1, 2로 하는건지 찾아보니

이 상품이 이 색깔인 거고, 빼지 않아도 됨

 

(이후 color table 따로 빼서 추가함. 

전체 목록 페이지에서 색으로 필터 하는 기능도 있음)

 

quantity수량은 주문, 결제, 장바구니에서만 있음  ( product option table로 뺌)

 

 

장바구니와 상품의 관계는? chatgpt- >다 대 다

 

결제 시 

장바구니를 꼭 거칠 필요없다

(바로 구매 있으니) 

 

 

product detail 테이블 

- content 1글자라도 있어야 하니 not nul

 

 

관계성 

주문 - 고객 여러명 

고객 1명이 - 주문 여러 개

 

 

상품: 주문 (한 상품은 여러 주문, 주문 하나는 상품 여러개 ) = 다:다 

상품과 주문은 다대다 
1개의 상품이 여러개의 주문에 들어갈 수 있고
1건의 주문에 상품이 여러개 될 수 있다. 

그럼, 
유저와 주문은 일대다  (일대다, 다대일로 구분하진 않어) 
1개의 주문에 한명의 유저
한명
공동구매는 다대다 

diagram에 쓰는 법

크다 작다로 

> 

큰 쪽이 다 

>  : 다 대 1 

 

다대다는 직접 잇는 게 아니라, 중간 테이블이 있으니, 1대 다 , 다대1로 

 

1대1은 - (작대기) 

 

 

 

order_detail table

order_detail로 굳이 따로 빼는 이유는 

주문정보만 따로 가질 필요가 있기에. 

나중에 회원정보나 주문 정보에서 보기보다, 누가 뭘 언제 주문했는지 보면 좋으니 

 

결제

amount를 총량으로 

 

1:다 (결제 한 건은 고객 1건 /고객이 여러 결제 가능)

주문페이지에 product연결 돼 있으니, order- product join 을 하면, 

여기에 파생된 거로, product -> product detail -> product detail안의 image 로 

해서 order과  연결됨. 

직접 테이블 하나씩 다 연결하는게 아니라, 연결해서 연결해셔 연결로 

 

 

 

폰번호는 문자열로 취급

(-dash로 생각해야 하니)

int는 정말 숫자의 개념이라 

 

테이블 많을수록 좋은가? 

관계성은 테이블이 많아서 어렵지만, 

장기적으로 볼때, 테이블 많은게 나음

 

이 테이블 하나가, migration file

 

방향성

고객이 주문부터 결제까지니까

배송 관련은 뺐다.

그와 같이, 재고도 고려할지 말지 고민

(이후 멘토님과 리뷰 후, 고려하기로 했다) 

 

 

리뷰 및 수정 전

리뷰 및 수정 후

 

---

멘토님 리뷰

category table

- 닥터마틴의 카테고리 

(ex. 마켓컬리- 뷰티/푸드 인거처럼)

 

 

기업협업은 팀 규모가 중요 --> 작은 팀은 3명 큰 팀 10명 넘는 팀 

오퍼는 25프로 (그중 절번) 

(지역, 고려 -> 거리 , 내용은 비슷, 

10-11개 

 

sub-category 추가 

--> 대분류 소분류가 명확한 페이지고, 자주 변경되지 않음. 

 

---

 product, product-detail 분리한 이유?

 

(정보가 많으니, product로 다 가져가기 heavy할 거 같아서, 

이미지 /글 /이미지 /글 --> 이 순서를 프론트에게 알려주거나 (그래야 이미지 여러개 들어갈 수 있음 )

html로 binary로 통으로 

 

디테일 이미지만 따로 관리하고,

 

---

product thumbnail 테이블

 

메인페이지에서 2장짜리로 보이는거 때문에 넣었는데 

필요 없음

 

thumbnail table 지우고,

image table 안에 'isthumbnailimage or isdisplayed'

(Product에 썸네일 이미지 바꾸고 싶을 때, 테이블 2개면 작업 두번 해야하니)

 

문구는 양 줄이고,

---

product-options table

_> filter에서 보이는 '색깔별로, 사이즈별로' 

--> color는 따로 뺴서 정규화 (테이블 따로 빼서 foreignkey) 

 

이유가 중요.

만약, 초록으로 빼면, varchar로 받게 되면, select where color_id=3으로 못하고, select where color=green 해야하니. 

 

재고 잇어야 품절 알 수 잇으니 --> quantity 추가

---

 

color 테이블에 

색깔에 기호도 있어야 함 (프론트랑 얘끼해서 빼도 되고)

 

 

 

---

option에서 size는 안 빼고 될 거 같음

 

---

장바구니 

장바구니 담을 때, 사이즈 선택 (옵션)이 필수로 뜸

 

 

브라우저가 기억하는 거 (로그인하기 전에 담은 거 기억) 

 

 

 

product_cart

product_quantity

product_options

product_orders -> 유저(누가 샀는지), Ordernumber(주문번호), ordername(주문자와 받는자가 다를 때), orders에 product가 들어가는게 아니라, 사실상 Product_options가 들어가는 거, 

(product_option_id) 

 

 

일반 order와 productorder차이는,

order는 주문결제정보

producorder는 어떤 상품을 주문했는지

---

(1) cart 장바구니 없을 떄 

주문상태

order-status 

1. 주문 전 (장바구니)

2. 주문 완료 

장바구니에 담고나서 결제하면 (장바구니에서 삭제 후, 결제 테이블에 가져가야하ㅁ녀 2번 일하니)

--> orderstatus로 1번, 2번으로 나눠서. 

그러면, 

장바구니에 담는 순간 order가 생기는 것 (완료되지 않은 order) 

 

그러면 order안에도 status가 있어야 (

 

부분결제 시

3개 담아놓앗는데 1개만 사면, 통째로 넘기고, 안 산거를 2개를 따로 만든다

(장바구니 없고 다 order에 들어갈떄

 

 

---

(2) cart 살린다면

한번에 다 주문하는 경우가 없기에, 

일괄결제

 

그리고 카트에 담았다 뺐다가하는 경우 많으니까

 

orders에는 결제 시점에만 (시점이 

 

 

고객관리로, 장바구니에 넣엇다가 결제까지 얼마나 걸릴까 알고 싶을때,

장바구니에 담아놓고 결제 오래 안했어 그럼 우리 상품이 문제일까? 해서 알고 싷을때, 

얼마나 오랫동안 담아놓았는지 알고 싶을때,

그러면 할인쿠폰 받아서 결제 유도하고

삭제했는지 status (deletedat) 칼럼ㅇ르 또 넣음 --> 커머스 회사의 데이터 분석팀 (customer teasing, 필요한 걸 적재적소에 주는)

 

 

마케터들이 sql 배워야 한다고 하는 게 이런거때문인데 사실 관계형 데이터베ㅣ읏 수업을 들어야 하는건데, 

sql을 배우는게 아닌데,

 

만약 cart

 

---

비회원일 때는

프론트가 관리 (누군지 우리가 알 수 없으니)

 

브라우저 storage에 따라 달라서, 그래서 로그인 토큰 사는거고, 그래서 비회원이여도 장바구니에서 담을 수 있는 이유는

프론트가 넣어놓았다가, 로그인할때, 토큰 저장하듯 브라우저 저장소에 들어가는 것. 

 

 

 

createdat, updatdedat, quantity는 product carts

 

 

products orders도 product carts와 거의 비슷 (product_id로 받아오면 되니, product_name필요없음. id를 가져오면 price도 join해서 다 딸려옴)

 

---

payments : userid, orderid (ordernumber는 orderid에서 가져오면 되니 필요없고), createdat, amount, status, 

method는 정규화--> payments_method테이블(결제수단) 

 

--> payment_log : 결제기록 남기는 카드 정지, 네트워크 오류 등 이력 남기는 (보통 pg사에서 해주는데 우리가 log를 남기기도 함)

(와 이런식이면 개발자만 있으면 사업 가능하겠네, 근데 툴 다 있지 않나
토스페이먼츠도 대신 결제를 해주고, 우리도 데이터베이스에 저장하라고 준다. 1년에 한번씩 관리해주는 비용도 내주고)

---

 

review:

createdat, userid 

 

같은 리뷰가 여러 개 가능한가? (= 다대다)

리뷰 많아보이게 다른 리뷰를 갖다 붙이는 경우

젝시믹스가 그럼 --> 빨간색 레깅스 샀는데, 검정색 레깅스 리뷰를 갖다 붙임 

--->그러면 review, product_review  가 필요함

 

근데 지금은 필요없음. 

 그럼 1대다

 

만약 닥터마틴에서 같은 사용자가 여러 리뷰 같은 거 남기면 위 경우에 해당 안됨

--> review id가 다르고, createdate도 다를 것이기에 

 

 

cart, product order, product carts --> product가 아니라, products option로 

 

하면서 데이터베이스에 수정 되면,erd도 같이 수정. 

 

 

그럼, product가 아니라, products option로 하면, products에 담는거면

 product(option을 통일하는 공통된 이름)

 

장바구니에  줄이 하나씩 들어가니까, (검정- 220 담기, 검정 250이렇게 한번씩 한번 가져가야 함)

 

 

product_cart- 누가 어느 상품을 하는건지

product-option 1개가 product-cart 여러개 담길 수 있음. ( 같은 색, 같은 사이즈여도, product id가 다름 

1줄이 여러 줄이랑 연결될 수 있느냐 

1대다 

 

(카트에 한번 담을 때 하나 선텩해서 하나만 넣으니까) 장바구니에 여러개 담기지만 실제론 따로따로 담긴거지

상품이 230이면서 240이 가능하느냐

 

사실상 product_cart는 user와 product의 중간테이블이다~

바라본다는게 fk로 물고 있다

---

credits

굳이 연결할 필요없다- 주문하면 차감하는걸로

---

이커머스니까 쇼핑몰이니까 이렇게 많은거지. 

일반 기능개발 시 erd쓴다.