어떤 상품에 대하여 프로모션을 진행해야한다는 상황을 가정하고 테이블 설계를 진행해보았다.
아래와 같은 요구사항을 적용
- 다양한 프로모션을 생성할 수 있어야함
- 특정 유저에 대하여 타겟팅 가능해야함
프로모션 생성
각 프로모션이 서비스 내에서 하나의 카테고리로 분류될 수 있지않을까? 싶어 promo_category라는 이름을 사용하게되었다.
단순히 상품과 프로모션을 묶어주는것으로 시작하여 적용된 상품 그룹별 노출 순서를 정하거나 구매수량 제한등의 옵션들을 컬럼으로 관리할 수 있지만..
이렇게 할 경우 같은 프로모션 카테고리를 적용하지만
특정 유저 대상으로 할인율 혹은 부가적인 적용조건을 다르게 하는경우 번거로워질 것 같다.
프로모션은 하나인데 타겟하려는 그룹에따라 row를 여러번 생성해야하는 상황이 발생하면서
그와 동시에 상품에 각 프로모션의 id를 타겟팅해야한다.
운영목적의 데이터 추출시 혼선이 있을 것으로 예상됨
프로모션 그룹화
이전 단계에서 있던 이슈를 보완한 버전이다.
한 종류의 프로모션을 생성하고 여러 형태로 찍어내기 위해 promo_controller 테이블을 추가했다.
하나의 프로모션이 시작된다고 가정할 때
구매상한수량, 종료일자 등의 부가조건이 다른 여러 컨트롤러가 하나의 프로모션 그룹으로 묶이는 형태로 생성될 수 있다.
유저 타겟팅
각각의 프로모션 컨트롤러를 찍어내고 각각의 유저마다 관계를 형성하려니
컨트롤러의 id를 유저와 엮어줄 매개가 필요해서 user테이블에 json 컬럼 하나 만들어서 관리할까 싶었지만
나중에 스토어에서 필요한 다른 상태값을 관리하게된다면 별도의 테이블이나 관리영역이 필요할 것 같다고 판단되었다.
위와 같은 이유로컨트롤러의 id를 유저별로 관리할 목적으로 user_store_subscription 테이블을 추가하였다.
이렇게 할 경우 클라이언트 사이드에서 유저에게 구독된 프로모션 상품 혹은 프로모션 카테고리를 노출시킬 수 있다.
유저별 프로모션 구독 정책
운영상의 목적으로 프로모션이 갑자기 생기거나 사라질 수 있는경우를 생각해보면
각 유저마다 프로모션을 구독시키는 방법도 고려해봐야한다.
- 요청이 들어올 때마다 스크립트를 작성하여 구독정보가 있는 테이블을 업데이트한다.
- 각 프로모션 컨트롤러에 타겟팅할 유저의 필터를 넣어두고 정기적으로 업데이트 할 수 있도록 한다.
위 두가지 방법이 떠올랐는데 첫번째 방법은 프로모션이 그리 자주있지 않다면 괜찮을 수 있지만..
나중에 귀찮아질 것 같기도하고 두번째 방법으로 진행하는 것이 좋아보인다.
컨트롤러에 subscribe_condition 컬럼을 추가하였다.
구독로직이 작동할 때 subscribe_condition에 담겨있는 필터조건으로 유저를 조회하여 컨트롤러 id 리스트를 업데이트 할 수 있다.
자주 사용되는 조건의 필터가 있다면 json으로 기록하지 않고 별도의 구독조건 테이블에 저장해둔뒤 fk로 엮어줄 수 있어보인다.
프로모션 상품 구매이후 구독 해지를 시키는 방식으로 운영한다면 해당 유저에겐 상품을 안보여줄 수 있다.
로깅
프로모션 상품 구매당시의 정보를 스냅샷형태로 유지할 목적으로promo_purchased_log 테이블을 생성하였다.
구매 이력을 row 단위로 관리하고 취소시 is_cancelled 컬럼을 업데이트하여 soft delete 한다.
부분 취소의경우 해당 수량정보가 있는 row를 is_cancelled 상태로 테이블에 삽입한다.
구매당시 구매이력을 참조하여 프로모션 중복참여을 막는데 이용할 수 있어보이고..
만약 구독정보를 제거하지않고 통계정보에 활용한다고 생각했을 때, 이 테이블을 참조하여 상품노출제한을 걸어볼 수도 있다.
결과물
지금까지 기록했던 모든 내용들을 반영하고 일부 테이블정보를 약간 수정하였다
Github에 레포지토리를 하나 만들어두었다.
dev4hobby:promo_tables
