배달앱 프로젝트

우리의 입문 프로젝트는 배달앱이다. 그리고 파트는 도메인별로 나누면서 각각 담당을 정했는데 나와 다른 팀원 분은 상품(음식) 파트를 맡았다.
도메인별로 한 명이 해도 되겠지만 우리의 경우 상품이 입점사(가게)와도 연관이 되어있고, 또 상품에 대한 카테고리까지 설정할 계획이기 때문에 2명이 맡게되었다.

ERD 작성하기

ERD는 전체적인 틀을 다른 팀원분들과 함께 만들었는데, 이 때 우리는 카테고리에 대하여 따로 테이블을 만들지 않고 입점사와 상품에 속성값으로 추가한 뒤에 스프링 배치를 사용하자는 이야기를 했었다.

그렇기 때문에 일단은 상품 id나 설명, 카테고리 등을 추가해서 ERD를 만들었다. 그리고 오후에 우리가 만든 ERD와 저번 주에 만든 요구사항 명세서를 통해서 API 명세서를 만들어보는 작업을 시작했다. 솔직히 Post인지 patch인지 delete인지 등을 검색해보고 확인해보면서 작업하는 건 크게 어렵지 않았다. 상품에 대한 추가, 조회, 수정, 삭제를 일단 단건으로만 추가해주고 장바구니 부분도 단건부분만 추가해주었다.
그러나 이 때 카테고리 부분에서 문제가 발생했다.

1. 카테고리는 어떻게 하지?

우리는 처음에 상품 url이 items로 시작했기에 카테고리도 속성값이라고 보고 items/category 형태로 url을 적어보았다.

그러나 아무리 봐도 API 명세서를 보고 명확하지 않다는 감상이 들었다. 뭔가 이상했다. 그도 그럴 것이 우리 프로젝트에서 category에 대한 것은 추가, 수정, 삭제의 경우 관리자 권한이 필요했지만 조회의 경우 일반 사용자까지 전부 가능해야 했기 때문이다.

처음에는 그런 의미로 도대체 어떻게 해야할지 몰라 튜터룸을 찾았다. 그러나 튜터님께 듣기로는 애초에 카테고리를 테이블로 만들지 않고는 추가, 수정, 삭제 등을 어떻게 할 것이며, 만약에 스프링 배치를 사용한다면 카테고리가 무한증식하는 문제는 어떻게 제지할 것이냐고 하셨다.

결국 우리는 또 다시 회의에 들어갔고, 카테고리를 별도의 테이블로 만들기로 결론을 냈다.

2. 카테고리와 입점사, 카테고리와 상품?

회의가 끝나고 상품 담당을 함께하는 분과 따로 ERD에 카테고리 테이블을 설정해보았다. 카테고리와 입점사가 N:M으로 연관이 되고, 카테고리와 상품 또한 N:M으로 연관이 되어야 했기 때문에 나는 ERD 수정을 할 때 카테고리, 카테고리-상품, 카테고리-입점사로 카테고리와 매핑테이블 두 개를 추가했다.

다대 다 연관관계를 해야한다고 생각했기에 아래와 같은 형태로 매핑 테이블을 구성했었다.

카테고리 테이블 양쪽으로 매핑테이블을 구성한 것이다.

3. 카테고리에 대한 고민들

그러나 그 와중에 팀원 분들께서 카테고리 테이블을 매핑하지 않고, 그냥 따로따로 입점사와 상품에 두자는 이야기가 나왔다.

복잡성을 낮추기 위한 선택을 하기 위해서 이런 식으로 하려고 했으나, 이렇게 하면 나중에 검색 할 때3중 조인을 하게 된다는 문제가 발생한다는 걸 기술팀장님이 캐치해주셨다.

결국 우리가 필요한 것은 어느 입점사에 어떤 카테고리 품목이 있는지이다. 따라서 매핑되지 않은 카테고리 테이블이 2개라면, 2번의 필터를 거치는 것이라고 보면 된다.
이 때 입점사 카테고리에서는 한 번만 조인하면 검색이 가능하지만, 상품 카테고리 기준으로 검색을 하게 되면 상품 카테고리->상품->입점사 순으로 조인을 해야하기 때문에 결과적으로 3중 조인을 하게 된다. 그렇기 때문에 우리는 카테고리 테이블은 하나만 두고 다시 매핑 테이블을 두는 방향으로 수정에 들어갔다.

결론

결론적으로는 우리는 두 개의 카테고리 테이블을 매핑해주는 것으로 ERD를 수정하게 되었다. 설계상으론 N:M 관계이지만 테이블 구조 상으로는 이를 해소해줘야 했기에 중간에 매핑테이블을 하나 두는 것으로 해결을 본 것이다.

이렇게 해서 입점사 - 카테고리 - 상품이 테이블 구조 상으로는 N:M이 아니지만 실제로는 N:M 처럼 동작할 수 있도록 매핑을 해 주었다.