[order-manager] Order-Manager-Product Table

[tonykang22]

Order-Manager-Product Table

개요

• 기능 요구 사항을 만족하기 위해 영속성을 활용해야 한다.
  • 기능 요구 사항 일부 : 완료되거나 취소된 주문에 대해서 내부적으로 데이터를 쌓는다.
• Order-manager의 work-flow는 메소드 실행 간에 일정 시간을 두고 작업이 진행되는 특징이 있다.
  • 아마존 상품 구매 요청 시
  • 아마존 상품 발송 여부 확인 시
• 한 주문에 대한 작업이 중간에 예외로 인해 중단되면, 중단된 지점부터 다시 시도해야한다.
  • 예) 상품 구매 요청은 했으나 배대지 신청서 작성 단계에서 예외가 발생한 경우 : 배대지 신청서 작성 단계부터 시작해야한다.
• 현재는 내부의 큐를 규현해두어 런타임 시에 활용이 가능하도록 구현해둔 상태이다.
  • 어플리케이션이 중간에 예기치 못한 에러로 중단이라도 된다면 모든 데이터를 잃게 된다.
  • 추후 Admin 모듈에서 활용할 가치가 있는 데이터를 인메모리에서 소멸하게 된다.

Order-Manager-Product Table 설계

Table 'order'

• id (BIGINT(20))
  • 기본키는 id 값으로 자동생성해 부여하도록 한다.
  • 괄호 안의 20은 ZEROFILL로 조회 시 부여되는 0의 갯수와 관련된 수이다.
  • Long으로 테이블 생성 시 BIGINT(20)으로 생성되기에 20으로 설정.
• product_id (BIGINT(20))
  • 외래키는 product table의 id로 (product_id) 후에 admin에서 판매된 상품 통계 등을 확인하는데 활용될 예정이다.
  • order-manager-product 와 product 테이블은 다대일 관계이다.
• order_id (VARCHAR(32))
  • 판매된 상품 건의 id로, 판매된 상품, 구매자 정보 등을 확인할 수 있다.
  • 참고 : 쿠팡 16자리, 11번가 17자리, 네이버 16자리, g마켓 10자리
• purchase_agency (VARCHAR(16))
  • 상품을 구매 요청한 업체명을 의미한다.
• purchase_agency_request_id (VARCHAR(32))
  • 상품을 실제 구매 요청 시 반환받는 id 값이다.
  • 참고 : Zinc API 32자리, Taobao open API 25자리
• delivery_agency (VARCHAR(16))
  • 배송 대행 업체명을 의미한다.
• delivery_agency_request_id (VARCHAR(32))
  • 배대지(Freight Forwarding Company) 요청 시 반환받는 id 값이다.
• international_courier (VARCHAR(16))
  • 해외 배송사의 업체명을 의미한다.
• international_tracking_number (VARCHAR(32))
  • 해외 배송 시의 송장 번호를 의미한다.
  • 약 50 개의 택배사 송장 번호 확인 결과, United States Postal Service가 26자리로 가장 길기는 했다.
• domestic_courier (VARCHAR(16))
  • 국내 배송사의 업체명을 의미한다.
• domestic_tracking_number (VARCHAR(32))
  • 국내 배송 시의 송장 번호를 의미한다.
  • international_tracking_number와 동일한 이유로 VARCHAR(32)로 결정했다.
• current_status (VARCHAR(32))
  • 현재 주문된 상품이 어떤 상태의 작업을 진행하는지 의미한다.
  • 예외 상태 또한 포함한다.
• sold_date (DATETIME)
  • 판매사에서 상품이 팔린 시간을 의미한다.
• purchase_agency_request_start (DATETIME)
  • purchase_vendor를 통해 상품 구매를 요청한 시간을 의미한다.
• purchase_agency_request_complete (DATETIME)
  • purchase_vendor를 통해 상품 구매가 완료된 시간을 의미한다.
  • 현재 Zinc API를 사용 시 병목으로 예상되기 때문에, 추후 AVG 등을 활용, 구매요청 ~ 구매완료의 시간을 확인할 수 있다.
• international_shipping_start (DATETIME)
  • 해외 배송 시작일을 의미한다.
• international_shipping_complete (DATETIME)
  • 해외 배송 완료일을 의미한다.
• delivery_agency_shipping_start (DATETIME)
  • 배대지 배송 시작일을 의미한다.
• delivery_agency_shipping_complete (DATETIME)
  • 배대지 배송 종료일을 의미한다.
• cancel_date (DATETIME)
  • Coupang API를 통해 취소/환불 요청이 확인되는 시간을 의미한다.

정규화 고민

• 다음과 같이 3차 정규화(이행적 종속 관계를 제거)를 위해 테이블을 나누기 시작하려니,
• 테이블이 적어도 5개가 더 필요하다고 판단되었다.
  • 판매사 관련 테이블
    • 판매/취소 날짜 테이블
  • 구매사 구매 요청 관련 테이블
    • 해외 배송 날짜 테이블
  • 배대지 요청 관련 테이블
    • 배대지 배송 날짜 테이블
• 그렇게 고민을 하다보니, 애초에 정규화의 목적인 이상현상에 대해 고민하게 되었다.

이상현상

• 이상현상이란?
  • 릴레이션 처리 과정에서 불필요한 데이터 중복으로 인해 발생하는 부작용을 의미한다.
  • 릴레이션 안에서 데이터를 입력, 수정 혹은 삭제하려고 할 때 의도하지 않은 문제점이 발생하거나 불필요한 작업을 추가 수행해야 하는 곤란한 상황을 의미한다.
• 삽입 이상
  • 불필요한 데이터를 함께 입력하지 않고서는 원하는 데이터만 입력이 불가능한 상황을 삽입 이상이라고 한다.
• 갱신 이상
  • 중복된 속성 값 중 일부가 수정되지 않을 경우 데이터 불일치가 발생할 수 있다.
• 삭제 이상
  • 삭제할 때 원하지 않는 유용한 데이터까지 함께 삭제되어 데이터 손실이 발생할 수 있는 상황을 삭제 이상이라 한다.

결론

• 현재 'order' 테이블 특성 상, 이상현상이 발생하지 않을 것으로 판단한다.
• 삽입 이상
  • 상품이 주문되자 마자 취소가 될 수도 있고, 주문 진행 취소될 수도 있기 때문에 많은 컬럼들이 NULL을 허용한다.
  • 즉, 불필요한 데이터를 입력하지 않아도 되기 때문에 삽입 이상이 일어나지 않을 것으로 판단한다.
• 갱신 이상
  • 테이블 특성 상, 중복된 속성 값은 없을 것으로 판단한다.
• 삭제 이상
  • 모든 주문 건에 대한 기록을 남기기 위함이므로 애초에 삭제 기능을 사용하지 않는다.
• 그러므로 테이블을 분리해 사용할 필요가 없는 것으로 판단된다.

[tonykang22]

정규화 관련

• order 테이블의 정규화 관련 결정의 기준은 다음과 같다.
  • order 테이블에서 DATETIME 값들을 가지고 있는 이유는 추후 Admin에서 각 상품별, 아니면 판매 날짜 기간 별, 배송 소요 시간 및 요청 처리 시간 등을 파악하고 활용하기 위해서이다.
  • 해당 작업을 수행하는데 성능을 최우선으로 고려하도록 한다.
  • order 테이블 특성 상, 이상현상이 발생하지 않을 것으로 판단한다.
• "정규화한 order 테이블"을 사용했을 시, Admin에서 원하는 데이터를 활용하기 위해서는, 여러 번의 조인을 통해 데이터를 조회하게 되기 때문에 단일 테이블로 데이터를 관리하는 것보다 오버헤드가 발생할 것으로 예상된다.
• 또한, order 테이블은 이상현상이 발생하지 않을 것으로 판단되기 때문에, 이슈에 첨부한 "정규화한 order 테이블"은 과도한 정규화(over normalization)이 발생했다고 생각된다.

결론

• order 테이블은 단일 테이블 설계로 결정한다.

참고

출처 : techtarget.com

• Reference post : Database Normalization vs. Denormalization