모놀리식 팀 프로젝트에 들어가면서 초반 ERD와 테이블 설계 등등을 설계하는 도중 들었던 고민들과 그 결과를 정리해두려 한다.
일단, 이번 프로젝트는 주어진 요구사항에 맞춰 개발해야 하는 프로젝트이다.
🔹요구사항
🔹테이블 명세서 및 ERD
30조 테이블 명세서 | Notion
1. 사용자 테이블 (p_users)
teamsparta.notion.site
ERD
주문 테이블과 상품 테이블은 N:M의 관계를 가지게 되므로, 두 테이블 간의 매핑 테이블(p_orders_products)를 만들어두었다. 또한 AI를 통해 상품 이름을 추천받을 수 있어야 하고, 결과물을 DB에 저장해야 하기 때문에 AI 관련 테이블도 만들었다.
가게에 딸려 있게되는 음식 카테고리나 지역 카테고리는 추후 테이블 컬럼이 추가되거나 변경될 가능성이 많아서, 확장성을 고려해 테이블을 따로 분리해 외래키로 참조하도록 만들었다.
🔹API 명세서
모든 도메인의 API 들은 CRUD와 Search (검색조건 및 정렬 기능)이 구현되어 있어야 한다는 필수 기능에 맞춰 구현했다. 일단 협업 시에는 노션을 사용해 API 명세서를 작성하고, 추후 개발이 완료된 후 Postman으로 API 명세서를 다시 작성할 예정이다.
30조 API 명세서 | Notion
Built with Notion, the all-in-one connected workspace with publishing capabilities.
teamsparta.notion.site
🔹인프라 설계도
상품 이미지는 S3를 통해 저장하고, PostgreSQL은 도커 또는 RDS를 통해 띄우려고 한다. (인프라 설계도 또한 추후 사용 기술 변경에 따라 바뀔 가능성 有)
++) 기술적 의사 결정 및 의논 사항들
1. 장바구니 기능을 추가한다면, 테이블이 따로 필요할까? 장바구니는 세션에 저장해야하나 DB에 저장해야하나?
1-1. 그렇다면 중간 테이블을 둬야할까?
세션에 저장하게 되면 클라이언트 쪽에 부하를 줄 수 있고, 유저가 폰에서 보든 웹에서 보든 멀티 디바이스 체제에서 저장된 값이 똑같아야 하므로 DB에 저장해야 한다.
그렇다면 N:M 관계가 되므로 중간 테이블도 만들어주기로 했다.
(++ 하지만 장바구니 기능은 필수 구현사항에는 없으므로, 필수 구현사항을 다 구현한 후 시간이 남으면 만들기로 결정)
2. 왜 ID를 Long 타입으로 auto increment 설정하지 않고 UUID로 구현하라고 했을까?
필수 요구사항인 PostgreSQL에선 UUID 타입을 DB 자체에서 제공해주니 편하고, 타입에러를 사전 방지할 수도 있을 것 같다.
( ++ 멘토님께 여쭤보니 실무에서 무조건 PK id 타입을 UUID로 쓰는 경우는 드물고, PostgreSQL 쓰는 것이 확정된 상태면 주로 UUID를 쓰기도 한다고 하셨다.)
3. 유저 테이블에서, address의 테이블을 따로 만들어서 해야하나? 혹은 address를 기본 주소와 상세 주소로 나누어서 저장할까?
배달의 경우 유저가 한 개 이상의 주소를 설정할 수도 있어야 하므로 한 유저 당 여러 주소를 저장할 수 있어야 한다. 따라서 address 테이블을 따로 만들고 FK 설정 해 주어야 하고, 주소 API에서 받아오는 기본 주소와 사용자가 입력하는 상세 주소를 따로 DB에 저장해주면 된다.
4. 상품의 option까지 구현해야하나? 구현 시엔 어떻게 설계?
위의 address와 동일하게, option은 상품 테이블의 자식 요소가 되야할 것 같다. 따라서 상품에 따라 추가될 수 있는 option 테이블을 따로 만들고, 상품 테이블에서 참조하는 식으로 만들자.
( ++ 이것 또한 필수 요구사항에는 빠져 있으므로, 모든 사항 구현 후 시간이 남으면 하자)
5. DB는 도커로 띄울까 rds로 띄울까? ( rds 선택 시 프리티어 가능 유무 및 사용료 지불 여부)
RDS로 띄우게 되면 프리티어가 있기는 하지만 과금 여지가 있다고 한다. 프리티어를 사용해 과금하지 않게 할 수 있긴 한데 설정이 복잡해서, 개발 초기에 편하고 빠르게 개발 진행하기 위해서 도커를 쓰기로 했다.
6. 가게 테이블의 컬럼인 음식 카테고리나 지역 카테고리는 어떻게 설계해야할까?
처음에는 가게 테이블 내의 음식 카테고리(e.g 한식, 중식, 양식, ...), 지역 카테고리(e.g 서울 종로, 광화문, ...) 컬럼을 String 타입으로 만들어서 설계했는데, 생각해보니 음식 카테고리나 지역 카테고리는 추후에 변경되거나 추가될 여지가 너무 많은 컬럼들이었다.
따라서 유지보수와 확장성을 생각해 따로 테이블로 분리하고 가게 테이블에서 FK로 참조할 수 있도록 하기로 했다.