옵션이 있는 상품 쇼핑몰 ERD 설계

Question

토이프로젝트로 이커머스를 만드려고합니다.상품은 여러 타입의 옵션 (의류를 예로들면 사이즈, 색상 등) 을 가지고 있고 옵션의 값을 가지고 있습니다.장바구니에 상품을 담고 주문도 하는 구조를 생각하고 있습니다. 따라서 링크와 같은 ERD를 그려봤는데요. 장바구니와 주문 테이블들이 상품의 어떤 옵션과 옵션값을 가졌는지 알기 위해서 장바구니 상품 옵션과 주문 상품 옵션 테이블을 따로 구성하는게 맞는지, 다른 방법은 없는지 피드백을 듣고싶어서 글을 남깁니다!https://www.erdcloud.com/d/FsjaAhzwumDddcHWJ

감독님테스트가하고싶어요 · Answer

회원 주문, 비회원 주문이 분리될 필요가 있을지 궁금하네요.회원 주문이 왜 회원 배송지를 참조해야하는지 잘 모르겠습니다. 배송지가 주문하고만 연결되어있으면 상관없겠으나 이게 회원이랑 연결되어있는데 그럼 회원 주문 후 회원이 본인 주소지를 변경하면 어떻게 되는건가요.설령 배송이 완료된 이후에도 회원이 주소지를 변경하면 나중에 기록을 확인할 때 &#34;실제 배송된 과거 배송지&#34; 가 아닌 &#34;변경 후 배송지&#34; 로 배송완료됐다고 뜨지않을까요?상품 옵션이 할인 쿠폰같은거라서 상품별로, 그리고 주문 전체에 대해 적용이 되는 것이 아니라 사이즈, 색상이면 주문 상품에 붙어있을 필요는 없지 않을까요? 상의, 하의 등의 상품의 색상, 크기를 정하는거지 (상의 M 보라, 하의 허리 30 검정, 신발 280 흰색 등) 을 구매하는 &#34;주문&#34; 에 크기와 사이즈가 어디있을까요? 장바구니쪽도 마찬가지네요.주문 상태를 테이블에 두고 관리해야할 이유가 있을까요? 일단 enum 코드로 박아넣고 필요성이 느껴질때 테이블로 빼서 관리해도 좋을 것 같습니다. 포인트 코드도 마찬가지입니다.

Clickin · Answer

굳이 옵션을 상품의 하위 테이블로 만들어야할까요한 판매페이지에 여러 상품이 들어갈 수 있고 이 구조에서 상품과 작성자께서 말씀하시는 옵션은 다를 바가 없다고 보입니다.옵션을 조합해서 나오는 최종 버전을 새 키를 따서 하나의 상품으로 취급하면 모델링이 깔끔해질 듯 합니다.

장독깨기 · Answer

전체적으로 잘 하셨네요.몇가지만 말씀드려보면,일단, 정보가 변경되지 않는다면 상관이 없지만, 실제 그렇지가 않잖아요.가령, 배송지 주소, 상품가격, 상품옵션 등이 되겠죠.그래서, 항상 정보 변경에 대해서 대비를 해야 합니다.방법으로는 변경 내역을 관리해서 그 당시의 정보를 조인해 보여줄 수 있습니다.근데, 때로는 이럴 경우가 필요하긴 하지만, 너무 복잡해집니다.그냥, 주문 정보에 주문 시점의 정보를 다 넣어두는 것이 간편할 것이고, 크게 문제 될 것도 없습니다.2, 상품에 상품옵션을 연결해두는 것은 맞습니다.근데, 역시나 주문상품에 연결만 하고 그 당시 정보를 입력하지 않는다면,옵션을 변경 했을 경우 대비를 할 수가 없습니다. 옵션별 가격이 있어도 마찬가지겠죠.그냥 주문 당시의 정보를 다 넣어두는 것이 간단할 것 입니다.3, 상품에 기본 가격이 없네요. 그럼, 무조건 디폴트로 옵션을 선택해야 할 것 입니다.물론 이렇게 해도 상관 없겠지만, 기본 가격을 두고 옵션에 따라 가감을 하는 것이 어떨까 싶네요.실제 옵션이 없는데 굳이 사용자에게 옵션을 선택하게 강요하는 것이 별로란 생각이 듭니다.운영자 입장에서도 마찬가지죠. 옵션이 없는데 굳이 입력을 해야 하는거죠.4, 주문을 회원, 비회원으로 굳이 분리할 필요 없어 보입니다.주문 정보를 조회하는데 별도로 조회하거나 합해서 보여줘야 하잖아요. 번거로워 보입니다.5, 주문상품 테이블을 보면 주문아이디와 상품아이디 외 주문상품 아이디를 키로 별도 생성했습니다.이렇게 해도 크게 상관없지만, 이러면 주문아이디 &#43; 상품아이디를 유니크 키로 제약을 해야 할 것 입니다.주문아이디 &#43; 상품아이디를 PK 로 잡는 것도 좋아보이고 더 간편해보입니다.이럼, 주문상품과 연결된 테이블들, 리뷰, 주문상품옵션등은 주문아이디와 상품아이디가 연결되겠죠.6, 윗 분도 언급했지만, 코드를 전부 별도 테이블로 관리하고 있네요.크게 상관없고 되려 정상적으로 보이는데요, 사실 좀 번거로운 부분도 좀 있습니다.나름 기준을 좀 정하면 좋은데요,가령, 주문상태 같은 경우는 변할 일이 잘 없죠, 굳이 따로 관리하지 않고 박아놔도 됩니다.포인트 같은 경우 보면, save, use 로 구분했습니다. 굳이 별도 테이블로 관리할 필요 없습니다.근데, 지금 설계 상에는 없지만 포인트를 지급하는 이유들이 있을 수 있습니다.이런 경우는 별도 테이블로 관리하는 것이 좋겠죠.그리고, 상품 유형 같은 경우도 여러 케이스에서 추가/변경될 수 있으니 별도 관리하는 것도 좋습니다.7, 근데, 한 상품에 대해서 유형이 여러개 들어갈 수도 있겠죠. 인기 &#43; 할인 이런 식으로요.1:1 이 아니라 1:n 으로 하는 것이 좋겠습니다.전체적으로 잘 하셔서 별로 지적할 만 한 것이 없네요. 잘 하실 거 같습니다.주절 주절 말씀드렸지만, 변경에 대한 대비 외에는 사실 취향껏 하더라도 크게 문제될 것은 없어 보입니다.마지막으로, ERD 편집 툴인데요,https://www.erdspace.com 여기 한 번 이용해보세요. 가독성이 더 좋을 것 입니다.열심히 하세요. :)

하아푸움 · Answer

테이블에 날짜관련 컬럼들이 없는 거 같네요. 등록날짜는 필수로 가지고 있으면 좋아요. 수정날짜는 목적에 따라 선택하시면 될 거 같네요.

옵션이 있는 상품 쇼핑몰 ERD 설계

4개의 답변

#erdcloud 목록