우버 (Uber)

이 스키마에 대하여

눈여겨볼 관계

users → driver_profiles

별도 계정이 아니라 역할입니다. 운전도 하고 타기도 하는 사람이 한 사용자이고, 승객으로서의 평점과 기사로서의 평점이 로그인 둘 없이도 구분됩니다.

rides → ride_tracking

표본마다 한 행인 시계열 경로점입니다. 운행 중에는 끊임없이 쓰이고 끝난 뒤에는 거의 읽히지 않아서 운행 행과 떼어 놓습니다.

rides → payments → driver_earnings

한 번의 운행에 세 행 — 청구한 것, 걷힌 것, 기사가 갖는 것. commission 이 그 차이이고, 바뀌는 요율에서 다시 구하지 않고 저장합니다.

ratings → users (두 번)

rater_id 와 ratee_id. 운행 하나가 서로 반대 방향의 두 행을 만듭니다 — 상호 평가가 늘 갖는 모양입니다.

promotions → promo_usages

사용 이력이 카운터가 아니라 운행에 묶인 행입니다. "이 사용자가 이 코드를 이미 썼나" 에 답할 수 있는 이유가 이것입니다.

설계 판단

자주 묻는 것

기사 위치를 왜 ride_tracking 에 두지 않나요?

배차가 여러 기사의 현재 위치를 한 번에 묻는데, 그중 대부분은 운행 중이 아니기 때문입니다. 시계열 테이블에서 기사별 최신 행을 읽는 것은 그 질의에 맞는 모양이 아닙니다. driver_profiles 의 컬럼은 덮어써지고, ride_tracking 은 실제 운행의 경로를 남깁니다.

요율이 ride_types 에 있는데 total_fare 를 왜 저장하나요?

요율은 바뀌고 할증은 순간이기 때문입니다. 오늘의 요금표로 가격을 다시 구해야 하는 운행은 지난 영수증을 설명하지 못하고, 이의가 제기된 청구에 답이 없습니다. 요금표는 현재이고 운행은 기록입니다.

승객과 기사를 따로 둬야 하나요?

한 사람이 둘 다 될 수 있다면 아닙니다 — 대부분의 시장에서 그렇습니다. 나누면 전화번호와 인증이 중복되고, 평가 시스템이 이름 하나 찾는 데도 두 곳을 봐야 합니다. driver_profiles 는 운전에만 해당하는 필드만 듭니다.

승객과 기사 매칭은 어떻게 하나요?

이 스키마가 하지 않습니다. 현재 위치 컬럼과 상태 필드가 입력이고, 배차는 그것을 지리 인덱스로 읽습니다 — 로그가 아니라 인덱스 걸린 컬럼인 이유가 그것입니다. 매칭 자체는 질의가 아니라 서비스입니다.

취소 수수료는 어디로 가나요?

모델링돼 있지 않습니다. cancelled_at 은 운행이 일찍 끝났다는 것만 말합니다. 수수료는 청구이므로 그것을 구분하는 타입과 함께 payments 에 들어가고 같은 운행을 가리켜야 합니다. rides 에 수수료 컬럼을 두는 방식은 수수료 종류가 둘이 되는 순간까지만 통합니다.