장바구니기능의 ERD와 API 명세서

새로운 팀프로젝트가 시작됐다. 이번 팀프로젝트는 배달 서비스 만들기. 평소에 매번 만들던 게시판 형식의 CRUD에서 벗어나 새로운 것을 배워보고 싶어 장바구니 부분을 선택하여 ERD와 API 명세서를 만드는 것에 도전했다. 기존 작성했던 것처럼 기본틀에 맞춰서 만들어나가고 있었는데, 고민에 빠졌다. 장바구니쪽 기능구현 방식에 따라 ERD의 테이블과 API 명세서가 달라지는 것이었다.

 

기존 선택 방식 (단일 테이블)

처음에 팀원들과 ERD를 그려나갈 때는 어차피 유저들이 장바구니를 하나씩만 가질 수 있기 때문에, 장바구니 테이블을 단일 테이블로 가는 것을 선택하였다. 그렇게 정하고 API 명세서를 작성하던중, 고민에 빠졌다.

 

단일테일블로 갈 경우, 유저들이 장바구니에 메뉴를 담으면 cart table에 메뉴가 하나씩 쌓인다. 이 경우 장바구니 목록에서 조회 할 때 모든 cart 필드를 조회해 userId로 필터를 해서 보여주어야하며, 주문시에도 또 다시 userId로 필터를 해서 가져와야한다. 우선 보통 장바구니 상품은 1개가 아니다. 그리고 장바구니에는 같은 restaurant의 메뉴만 담을 수 있기 때문에 restaurant_Id또한 불필요하게 반복된다.

 

고려한 방식(테이블 2개 cart, cart_detail)

우선 이 경우 주문으로 넘길 시 간단하게 cart_Id를 넘겨줌으로써 데이터를 가져올 수 있다.

그리고 restaurant과 같은 데이터의 중복을 줄여 필요로하는 정보에 집중해 데이터 일관성과 무결성을 유지하며, 데이터 베이스 성능을 향상 시키는 정규화를 진행하게 된다.

그리고 장바구니 관련 정보가 변경될 경우, 각 테이블을 독립적으로 수정할 수 있어 확장성을 갖게되며, 테이블이 목적에 맞게 구성되어 있어, 특정 장바구니에 담긴 제품 조회나, 몇개의 장바구니에 담겨있는지 쿼리를 통해 간단하게 작성도 가능하다.

 

 

결론

이러한 이유들로 cart 테이블과 cart_detail 두개의 table을 가지고 가기로했다.

이를 통해 정규화, 확장성, 쿼리 효율성의 장점을 가져갈 수 있게되었다. 그리고 지금은 작은 프로젝트지만 만약 나중에 실제로 일하게 되어 많은 데이터베이스 양을 담게된다면 데이터베이스의 성능 또한 최적화 할 수 있을 것이다.

 

** 추가로 오늘 배운 작은 팁. 가격 변동이 있을 가능성이 있는 상품은 실제 상품 테이블 외의 테이블에서는 컬럼을 따로 만들지 말아야한다. 반대로 만들어진 시점 이후로 가격 변동이 없어야한다면 가격 컬럼을 따로 생성해야한다!

(ex. 장바구니는 가격 변동을 반영해야해서 price 컬럼을 만들면 안되고, 주문조회같은 경우 추후 가격을 확인할 때 결제 당시의 가격을 반영해야 한다.)

 

앞으로 단순히 직관적으로 진행하기보다 이번처럼 여러가지 방법을 고려하여 효율성까지 가져가는 개발자가 되도록 노력해야겠다.