프로젝트/쿠팡이츠 클론코딩

[쿠팡이츠 클론코딩] ERD 설계

김긍수 2022. 3. 11. 02:31

ERD설계는 AQueryTool을 사용하였고 데이터베이스는 MySQL을 사용하였다.

 

쿠팡이츠 ERD 설계

 

1. User(유저)

쿠팡이츠 서비스를 이용하기위해 회원가입을 한 사람의 데이터가 쌓일 테이블 정보이다.

유저 번호는 기본키이며 auto increment 설정을 해주었다. 유저번호는 중복값이 없어야하기때문이고 1씩 증가하도록 해줄 것이다.

createdAt, updateAt은 레코드가 생성될 때, 수정될 때 시간이 자동으로 저장되게끔 설정해주었다.

joinType(가입수단)은 개발하려는 서비스가 일반회원과 카카오회원으로 나뉘기 때문에 넣은 컬럼이다. 이 컬럼이 없어도 상관없을거라고 생각할 수도 있지만, 쿠팡이츠는 카카오로 가입된 카카오 이메일과 동일한 이메일로 자체회원가입을 하게 되면 이미 카카오톡으로 가입했다고 알려주기도 하고 자체회원과 카카오회원을 나눠야만 카카오 로그인 접근 시, 제대로 확인할 수 있을 것이다.

status(상태)는 Y(활성화회원), N(탈퇴회원)으로 구분지어주었다. 여기서 탈퇴회원인 경우 레코드를 삭제할 수도 있지만 삭제하지않고 상태값 변경을 해주었다. 

 

2. Address(주소)

음식 배달을 위해 유저가 저장하는 주소가 담길 테이블이다.

유저가 주소를 저장하고 홈에서 주소를 선택할 수 있는데, 그 주소의 위치에 따라 근처 음식점을 조회시켜주어야하므로 컬럼에 위도, 경도를 넣었다. 또한 주소는 집주소, 회사주소, 기타주소(고객이 작성) 으로 나누어 저장할 수 있으므로 status(상태)에서 그 값들을 구분시켜주었다.

 

3. Store(가게), StoreCategory(가게카테고리), StoreImage(가게이미지)

 

4. BestMenu(추천메뉴), MenuCategory(메뉴카테고리), Menu(메뉴)

메뉴 관련 테이블이 정말 복잡했다. 왜냐하면 가게에 메뉴만 여러가지가 있는게 아니라, 각 가게별로 카테고리가 있었기 떄문이다.

이렇게 나뉘어져서 Store 안에는 여러 MenuCategory(세트메뉴, 엽기메뉴, ...)가 있고 이 안에 Menu(A세트, 엽기떡볶이, ...)가 있으며 Menu 안에는 또 여러가지의 MenuOptionCategory(메뉴선택1, 매운맛 선택, 추가메뉴, ...)가 있고 그 안에 MenuOption이 있는 것이다! 정리가 완전히 된 지금 보면 왜 이걸가지고 많이 고민했을까? 생각이 드는데 처음 이걸 보고 어떻게 테이블을 나누어야할지 잠깐 머리가 빙글빙글 돌았었다...ㅋㅋㅋㅋㅋ 그래도 깔끔하게 잘 나누었고 구현도 잘되었으니 고민한 내 자신이 만족스럽다! 1개의 메뉴에 대해 여러개의 이미지가 첨부될 수 있어서 MenuImage테이블을 추가하였다.

 

5. Review(리뷰), ReviewImage(리뷰이미지), MenuReview(단일메뉴평가)

쿠팡이츠에서 리뷰를 작성할때에는 여러 개의 사진과 내용, 배달평가, 메뉴평가를 선택할 수 있다.

1개의 사진만 첨부할 수 있다면 Review 테이블에 컬럼을 하나 추가했을테지만, 여러개의 사진을 담을 수 있어서 ReviewImage테이블을 만들어주었다. 또한 MenuReview 테이블은 리뷰 작성 시 자신이 주문한 각 개별 메뉴마다 좋아요 체크, 이유, 코멘트 들을 작성할 수 있어서 이것또한 따로 테이블로 만들어주었다.

 

6. Orders(주문), OrderMenu(주문메뉴)

유저가 메뉴를 주문했을 경우 데이터가 저장되는 테이블인 Orders와 OrderMenu이다. 

Orders테이블에는 전체적인 주문정보가 들어가고 OrderMenu에 각 주문에 대한 주문된 메뉴가 저장된다. OrderMenu테이블에 menuIdx(메뉴번호)만 저장한 후 나중에 어떤 메뉴를 주문했는지 조회할때 조인해서 불러올 수도 있겠지만! 여기서, 만약 주문한 후 며칠 뒤 가게 주인이 그 메뉴의 이름이나 가격을 바꿨다면????? -> 1월1일에는 3만원에 주문했던 것이 1월 3일에는 5만원이 되어 데이터가 이상해질 것이다. 따라서 나는 주문메뉴, 개수, 가격도 함께 저장해두었다. 그리고 메뉴에 대한 정보를 저장하는데 메뉴번호도 같이 저장한 이유는 가게별로 가장 많이 주문한 메뉴에는 [주문많음], [리뷰많음]이라는 텍스트알림이 뜨기때문에 컬럼값에 추가해두었다.

 

7. Coupon(할인쿠폰), UserCoupon(할인쿠폰소유유저)

가게마다 발행할 수 있는 쿠폰과 그 쿠폰을 가지고 있는 유저를 저장할 수 있는 테이블이다.

UserCoupon테이블의 redeemStatus(쿠폰적용상태값)은 유저'김긍수'가 A가게의 메뉴를 카트에 담고 주문하기 화면에 들어가면 가지고 있는 할인쿠폰이 자동으로 적용된다. 하지만 '김긍수'유저가 A가게의 쿠폰을 해제하면 그뒤부터는 자동적용이 되지않고 미적용이 된다. 클라이언트에서 할수도 있지만 우리는 클라이언트와 상의 결과 서버에서 해주었다.

 

8. ReviewLike(리뷰 도움돼요안돼요), Bookmar(가게즐겨찾기), Event(이벤트)

테이블 이름짓기가 애매한 것들이 많은 것 같다!!!

개발자의 가장 큰 고충 == 변수, 테이블, 클래스명 등등.. 이름짓기 ^^...

처음 프로그래밍언어를 배웠을 때부터 나만 느끼는 줄 알았는데 다들 그런다고 한다 ㅎㅎ

아무튼 ReviewLike테이블은 다른 사람이 작성한 리뷰에 도움이 돼요, 안돼요 라고 평가를 할 수 있는 버튼이 있는데, 누가 작성에 대한 평가를 눌렀는지 저장하는 테이블이다. 도움이돼요를 저장하는 테이블1개, 도움이안돼요를 저장하는 테이블1개 이렇게 2개로 나누는 방법도 생각했는데 사람들마다 도움이 된다고 했다가 안된다고 다시 누르게 되면 2개의 데이터가 생겨버리니 너무 낭비하는 느낌이 들었다. 그래서 1개의 테이블안에서 likeFlag를 이용해서 구분해주었다.

 

실제 서비스에서 필요한 테이블은 엄청나게 많겠지만 개발범위 내 이렇게 총 22개의 테이블로 설계하였다.