스파르타 12조 질문 정리

ERD 초안 )

 

Q1. 가게의 주소를 지역테이블로 관리할 때 설계방법 어느 것이 더 좋을까요?

첫 번째 방법 : 가게 주소를 셀프조인구조로

1. 상위지역컬럼을 셀프조인으로 설정, 상위 지역과 상세 주소 수준으로 구분한다.

ex) 서울 종로구 대학로 9길 23-2 1층

id : 1, depth 를 1, name을 "서울"로 저장, 상위주소는 null
id : 50, depth 를 2, name을 종로구, 상위주소는 1
id : 88, depth 를 3, name을 대학로 9길 23-2 1층, 상위주소를 2

결과적으로 서울 종로구 대학로9길 23-2 1층의 주소는 id 88로 저장된다.
문제) 너무 많은 조인을 하게 되지 않을까
장점) 확장에 용이

 

두 번째 방법 : 가게 주소를 하나의 컬럼으로 문자열로 저장한다.

2. 지역 테이블에 문자열로 address 컬럼으로 저장한다.
ex) {
location_id : 3,
adress : "서울 종로구 대학로9길 23-2 1층",
created_at : ...,
...
deleted_by :...
}

 

Q1-2 주문 배송주소

주문 테이블에서, 배송지를 회원 테이블을 통해서 가져오는 게 좋을까요?

아니면 따로 조회용 필드만 하나 기록해 두는 게 좋을까요?

 

저희는 일단 주문테이블에서 회원을 조회하고, 해당 회원의 배송주소테이블을 조회하는 식으로 하는 것보단
연관관계없이 배송지만 조회용으로 따로 컬럼을 추가해서 관리하는 걸 선택했습니다.

Q2. 주문 API 설계

요구사항에서는 실제로 토스 API로 결제 로직을 구현하지는 않는다고 해서
결제 결과에 따른 상태변경만 진행하려고 합니다.

 

이때 주문과 결제를 2개의 트랜잭션으로 나눴습니다.

주문의 상태를 ENUM으로 관리했습니다.

주문 절차에 따라서 ENUM값을 update 하는 방식으로 구현할 예정입니다.

주문 시나리오)

1. 주문생성(주문 API로 생성, 주문 상태를 "결제 대기"로 설정) 
2. 결제가 완료되면 주문을 가게로 요청합니다. ( 주문 상태를 "결제 대기" -> "주문 요청"으로 변경 )
3. 사장님이 주문을 확인 후 취소 or 승낙합니다.
4. 주문 승인
5. 조리 중
6. 배달

 

주문이 생성되기 전에
결제가 먼저 이루어지고, 결제 성공/실패에 따라서 주문을 생성합니다.

주문 요청 결제 API (토스 API결제, 실제론 그냥 상태 변경(결제대기 → 주문 요청) )

저희는 일단 이렇게 하는 게 좋겠다고 했는데, 튜터님 생각이 궁금합니다.

Q3. UUID를 사용하는 이유?

중간테이블도 PK를 UUID로 만들어야 할까요?