Home-Delivery 개념 모델링

home-delivery 프로젝트를 시작하게되었다.

이전까지는 프로토타이핑과 기능정의를 했다. 

개념모델링을하던중 고민사항을 글에 적었습니다.

 

home-delivery는 배달클론코딩 프로젝트입니다.

그래서 많은 앱들을 관찰을 하였습니다. 그러던중 배달의민족앱은 장바구니에 담아야 주문을 할수있도록 기능이 설계되어있습니다.

장바구니 기능이 존재하는 다른 이커머스 앱이나 웹을보면은 장바구니에 담지않고 바로 구입을 가능하도록 설계되어있습니다. 그래서 고민이있었습니다. 장바구니를 관계를 두어야하는지 아니면 개체로 생각하고 모델링해야하는지 고민했습니다. 직접 관계로 생각하고 해보니 모델링이 관계와 관계끼리 연결이되는 문제가 생겼습니다. 그로그인해 장바구니를 하나의 개체로 생각하였고, 설계한결과 더 깔끔한 모델링이 되었다고 생각합니다.

 

장바구니를 바라보는 시각에 따라 다른것같습니다. 장바구니개체가 존재하고 장바구니개체와 메뉴개체사이의 포함이라는 관계가 존재한다면 장바구니에 담긴목록들을 담는 중간테이블이 생성될것입니다.

그래서 유저는 장바구니를 1:1 즉, 현실세계와같이 카트하나를 가진다고 설계되었습니다.

 

다른 한가지 고민사항은 장바구니와 주문의 관계입니다. 주문도 하나의 개체이며 만약 장바구니에 메뉴목록들을 담는 테이블로생각하고 즉 위에와는 다르게 목록들을 담는 중간테이블이없다고생각하면은 장바구니에 메뉴목록들이 담길것이고 이것을 바로 주문테이블로 보내는 방법이 첫번쨰,

두번째는 장바구니 id를 주문테이블에 외래키로 생각하여 갖는 관계입니다. 첫번째와 두번째 둘다 같은것이다고 생각하지만, 저는 두번째방법이 괜찮다고생각합니다.

저는 장바구니목록을 모두 주문테이블로 보낸다면은 주문테이블의 row가 굉장히 많아질것입니다.

 

현실세계에서 주문을한다고하면 여러개의 메뉴를 하나의 주문이라고 생각합니다. 예를들면 배달 영수증에 찍힌것과같은

그래서, 제가생각하는 주문은 하나의 주문 (치킨, 양념치킨, 콜라)와같이  제가 원하는 테이블의 양식입니다.

위와같은이유로 두번째 방법을 선택한이유중 하나이며, 또 추가적으로

제1정규화를 지키기위해서 (주문id1 치킨), (주문id2, 양념치킨), (주문id3, 콜라) 이런식으로나온다면 사장님에게는 주문이 하나로 묶어지면 관리하기편하지만 사장님입장에서는 3개가 하나하나씩 주문이 들어오는 것은 매우 영수증을 받는다고가정하면 비효율적이다고생각합니다. 그래서 두번째 방법을 선택했습니다.

 

 

장바구니개체