SQL

자연 키 vs 서로게이트 키

자연 키(natural key)는 이메일이나 주문번호처럼 실제 비즈니스 데이터를 사용하는 키다. 서로게이트 키(surrogate key)는 비즈니스적 의미가 없는, 시스템이 생성한 식별자로 보통 자동 증가 정수나 UUID를 쓴다. 웨어하우스에서는 서로게이트 키를 선호하는데, 자연 키는 시간이 지나며 변한다 — 회사가 합병되고, 이메일 주소가 바뀌고, 제품 SKU가 재할당되기 때문이다. 정수 비교가 문자열 비교보다 빠르므로 서로게이트 키는 JOIN 성능도 개선한다.

웨어하우스가 FK를 강제하지 않는 이유

많은 클라우드 웨어하우스(BigQuery, Redshift, Snowflake)는 외래 키를 선언할 수는 있지만 쓰기 시점에 강제(enforce)하지는 않는다. 매 INSERT/UPDATE마다 무결성을 검증하는 것이 오버헤드를 더하기 때문이다. 그렇다고 이 키들이 무의미한 것은 아니다 — 문서화 역할을 하고, 쿼리 옵티마이저가 더 나은 실행 계획을 세우는 데 도움을 줄 수 있다. 실무적인 답은 '문서화를 위해 선언하되, 무결성은 파이프라인 상류(upstream)에서 강제한다'는 것이다 — 즉 04번 모듈(SQL 기초의 참조 무결성)에서 다룬 OLTP의 엄격한 FK 강제와 대조되는 접근이다.

복합 키, 후보 키, 대체 키, 카디널리티

복합 키(composite key)는 단일 컬럼만으로는 유일성을 보장할 수 없을 때 두 개 이상의 컬럼을 함께 사용하는 키다 — 예를 들어 order_line_items 테이블은 (order_id, line_number) 를 복합 키로 쓸 수 있다. 흔한 함정은 컬럼을 4개 이상 조합하는 지나치게 복잡한 복합 키를 만드는 것으로, JOIN이 장황해지고 오류가 나기 쉽다.

후보 키(candidate key)는 기본 키가 될 수 있는 모든 후보(유일하고 NULL이 아닌 컬럼 집합)를 말하며, 하나를 기본 키로 선택하고 나면 나머지 후보 키들은 대체 키(alternate key)가 된다. 예: employees 테이블에서 employee_id와 social_security_number 둘 다 후보 키지만, employee_id를 기본 키로 선택하면 SSN은 대체 키가 된다.

카디널리티(cardinality)는 두 엔티티 간 수치적 관계(1:1, 1:N, N:M)를 뜻한다. 카디널리티를 잘못 모델링하는 것은 가장 값비싼 실수 중 하나다 — 1:N 관계를 1:1로 모델링하면 행이 조용히 유실되고, 1:1 관계를 N:M으로 모델링하면 중복이 생겨 모든 집계 지표가 부풀려진다.