2-1. "일단 되는 대로" 만든 orders 테이블

아직 작은 스타트업 쇼핑몰이 있다고 가정한다. 개발팀은 서비스를 빨리 출시해야 해서 데이터베이스 설계에 많은 시간을 쓰지 않았다.

고객과 주문을 관리하기 위해 다음과 같은 orders 테이블 하나를 만들었다.

orders 테이블 구조

- order_id          : 주문 번호
- customer_id       : 고객 아이디
- customer_name     : 고객 이름
- customer_address  : 고객 주소
- product_id        : 상품 번호
- product_name      : 상품 이름
- product_price     : 상품 가격
- ordered_at        : 주문 날짜

실제 데이터 예시는 다음과 같다.

order_id customer_id customer_name customer_address product_id product_name product_price
1001 user1 네이트 서울시 강남구 P001 좋은 키보드 50000
1002 user2 이철수 경기도 성남시 P002 편한 마우스 30000
1003 user1 네이트 서울시 강남구 P002 편한 마우스 30000
1004 user3 박영희 서울시 서초구 P003 고성능 모니터 200000
1005 user1 네이트 서울시 강남구 P003 고성능 모니터 200000

처음에는 문제가 없어 보인다. 쿼리도 간단하다.

-- 특정 고객의 주문 목록 조회
SELECT *
FROM orders
WHERE customer_id = 'user1';

하지만 이 설계는 이미 여러 개의 시한폭탄을 품고 있다. 이 폭탄은 시간이 지나면서 다음 세 가지 큰 문제로 터진다.

  1. 데이터 무결성 훼손
  2. 성능 저하
  3. 유지보수 비용 폭증

각 문제를 조금 더 구체적으로 본다.

2-2. 데이터 무결성 훼손 – 이상 현상(Anomaly)

1) 데이터 중복

위 orders 테이블을 다시 보면 다음과 같은 중복이 눈에 띈다.