BigQuery vs. Traditional Relational

Problem framing

• Data is scattered across many tables → JOIN 지옥 + inconsistent “single source of truth”.

• Goal: one booking table everyone can trust (pickup/dropoff, status events, 등 비즈니스 컨텍스트 유지).

• Traditional 모델링: 정규화 = 중복↓ but JOIN↑.

  BigQuery: Denormalize with STRUCT/ARRAY = context↑, JOIN↓.

Modeling choice (Normalization vs Denormalization)

• Normalize (정규화): 작은 테이블 다수, FK로 연결 → update/write 편함, read 시 JOIN 많음.
• Denormalize (반정규화): 한 테이블에 context 담기 → read 빠름, 비용 예측 쉬움.
• BigQuery 특화 전략: Nested(STRUCT) + Repeated(ARRAY) = “둘 다의 장점” 가져오기.

Core concepts

• STRUCT (aka RECORD): typed field group. 서로 다른 타입 가능, 심지어 내부에 ARRAY 포함 가능.
• ARRAY (REPEATED): same-type 값들의 리스트.
• 한 테이블 안에 여러 STRUCT, 여러 ARRAY 가능 → 다중 granularities 공존.

Limit: ~100 MB per row (internal repr. 기준). 큰 중첩은 row size 주의.

Why nested?

• Business-friendly schema: 예) booking 안에 pickup, dropoff, status_events[] 같이 담기 → 맥락 유지 + 유일성 관리 쉬움.
• Read 패턴 중심 설계(analytics-first). 대부분 쿼리는 “한 건의 booking + 그 하위 이벤트들”을 같이 본다 → JOIN 없이 읽기.

Reading the schema

• STRUCT: booking.pickup.lat, booking.dropoff.lng처럼 dot notation.
• ARRAY: status_events 같은 반복 필드 → UNNEST로 row 전개 필요.