간단한 사이드 쇼핑몰 프로젝트를 구현하기 위해서 데이터 스키마 구조를 현재 구상하고 있습니다. 게시글의 목적은 현재 생각한 것들을 기록해두고 잊어먹지 않도록 하기 위함입니다.
현재 제가 구상한 유저와 계정 테이블은 다음과 같습니다.
원래의 예상하던 테이블 간 관계는 1:N으로 하나의 유저는 여러 계정을 가질 수 있다가 되겠습니다. 다만, NICE와 같은 여러 서드파티를 통해 구현을 진행했던 결과 CI 값은 사업자 레벨에서만 할당해주기 때문에 사이드 프로젝트에서는 사용할 수 없는 상황입니다. 그래서 CI를 할당받지 않고 차후에 확장을 하더라도 문제없는 구조는 어떻게 될까? 라는 생각을 하게 되었고 이에 대한 해결은 다음과 같았습니다.
현재로써 구조는 1:N이 아닌 1:1 형태를 선택합니다. 이 이야기는 즉슨, 동일한 명의에 다른 계정을 같은 계정으로 보지 않겠다는 뜻입니다. 어떻게 보면 나중에 구매 포인트 등을 도입하고 이 포인트를 합쳐줄 것이냐는 사업적인 구상도 필요하겠습니다만, 현재는 그 구조를 고려하지 않을 생각입니다. CI를 받게되어 이를 다시 마이그레이션해야 한다면 다음과 같이 생각할 것입니다.
- 현재 동일한 명의의 계정이 3개 가입되었다고 가정하겠습니다.
- 먼저 들어온 서드파티의 첫번째 유저 인덱스에 해당하는 로우 데이터의 CI를 업데이트합니다.
- 남은 2개 계정에 해당하는 유저 인덱스에는 CI가 없으나 다른 서드파티에서 얻은 CI를 통해 값이 있다면 2번에서 업데이트한 유저 인덱스를 각각의 서드파티 군별로 맞게 업데이트합니다.
- 기존의 계정 테이블의 값은 상태값을 MERGED 등의 ENUM 클래스 값으로 변경합니다.
이렇게 진행한다면 1:1 관계로 시작한다고 한들 1:N 관계로써 확장시킬 수 있지 않을까 생각합니다.