처음엔 FK로 참조하면 되는 거 아닌가 싶었다. 근데 주문 하나에 배송지, 상품, 할인까지 다 엮이기 시작하면 얘기가 달라진다.
간단하다. 데이터가 변경되기 전의 값을 그 시점에 복사해서 박아두는 것.
예를 들어 order_items 테이블에 product_id FK만 들고 있다고 하자. 나중에 상품명이 바뀌면? 주문 당시 상품명이 뭐였는지 알 수 없다. 그래서 product_name을 주문 시점에 직접 복사해두는 게 스냅샷이다.
FK는 현재를 참조하고, 스냅샷은 주문 당시 상태를 남긴다.
쇼핑몰을 예시로 보면 이런 일들이 생길 수 있다.
배송지가 바뀌면?
고객이 주문 후 배송지를 수정했다. orders.address_id FK가 가리키는 row가 업데이트되면 "이 주문이 어디로 배송됐냐"가 바뀐 주소로 보인다. 실제로 배송은 이미 예전 주소로 나갔는데.
상품 옵션이 수정되면?
판매자가 옵션명을 "블랙 / 256GB"에서 "스페이스 블랙 / 256GB"로 변경했다. 과거 주문에서 고객이 뭘 샀는지 정확히 알 수 없게 된다.
쿠폰/프로모션이 삭제되면?
프로모션이 종료되고 row가 삭제됐다. order_discounts.promotion_id FK가 가리키는 곳이 없어진다. CS팀이 "이 주문에 왜 이 금액이 할인됐냐"를 설명할 근거가 사라진다.
결국 FK로 현재 데이터를 그대로 참조하고 있으면, 원본 데이터가 바뀔 때 과거 기록도 같이 바뀌어 보인다. 이게 핵심 문제다.
모든 테이블에 필요한 건 아니다. "주문 당시 상태"가 중요한 데이터에만 적용하면 된다.
| 테이블 | 스냅샷이 필요한 이유 |
|---|---|
order_items | 상품명, 옵션명, 가격이 나중에 수정될 수 있음 |
deliveries | 고객이 배송지를 수정/삭제할 수 있음 |
order_discounts | 쿠폰/프로모션 조건이 변경되거나 삭제될 수 있음 |
반면 orders.user_id 같은 건 스냅샷이 필요 없다. user_id는 UUID로 한번 발급되면 변경되지 않는 값이기 때문이다.
팀에서 "hard delete 절대 금지, soft delete만 쓴다"는 정책을 강하게 잡으면 FK가 가리키는 row가 사라질 일은 없다.
근데 정책은 사람이 지키는 거고, 사람은 실수한다.
배치 작업 잘못 짜거나, 코드에 버그가 있거나, 팀원이 실수로 DELETE 날리면 그걸로 끝이다. 복구가 안 된다.
스냅샷은 "DB 정책을 믿지 말고 데이터 자체에 박아두자" 는 거다. 컬럼 몇 개 추가하는 비용 대비 얻는 안전성이 훨씬 크다.
결국 주문 시스템에서 중요한 건 "현재 상품 정보"가 아니라, "주문 당시 어떤 거래가 있었는가"를 남기는 거였다.
참고자료: medusajs/medusa Discussion #3103 Workarea - Order Pricing