Today I Learned
날짜
2024년 5월 3일 금요일
내용
DB구조에 대해 열심히 고민했다. 우리 서비스는 애초에 앱을 여러개 낼 계획이 없었기 떄문에 Shopify에서 받은 스토어 정보를 Shop 테이블에 저장하고 이 테이블을 중심으로 모든 로직이 이루어진다. 가장 최상위 테이블 역할을 한다. 알파리뷰 서비스에 가입한 계정에 관한 테이블인 ShopAdminAccount가 같은 계층에 있어 서로 참조할 수 있는 테이블이긴 하지만, 그외의 모든 데이터는 결국 Shop을 기준으로 정규화가 이루어져 있다. 따라서 서비스 삭제도 이 Shop을 삭제하면 이와 연관된 모든 테이블이 삭제된다(일부 남는 테이블과 리뷰서버 쪽도 처리하긴 해야 하지만…).
새로운 앱이 출시되면서 이 구조가 여러모로 문제가 될 소지가 많았다. 당장 하나의 앱만 추가한다는 생각으로, 억지로 구조를 짜넣으면 지금 당장에야 되긴 하겠지만 더이상 앱이 추가되거나 같은 앱 내의 별개 서비스가 추가되어 관리되야 한다면 문제가 발생한다. 별개의 앱이 같은 서버, 같은 데이터베이스를 사용하면서 독립적으로 작용하지 않아 생기는 문제들이다. 향후 유지보수나 확장성을 위해, 이 구조를 더 명확하게 처리하고 갈 필요가 있다고 판단했고 의논끝에 잡고 가도록 결정했다.
- 최상위 테이블인
platform을 신설한다. - 앱을 기준으로 최상위 테이블은
Shop으로 유지한다. 새로 만들 앱의 최상위 테이블은BrowseBoosterShop이 된다. - 앱이 달라도 알파리뷰 계정은 공유되기 떄문에 각 shop 테이블은
ShopAdminAccount테이블과 연관을 갖는다.
하나의 데이터베이스에 내에서 횡적으로만 엮이도록 하여, 서로 의존하거나 간섭하지 않도록 해야 한다. 전혀 생각하지 못한 부분에서 발생하는 에러나 예외사항을 방지해야 하기 때문이다.
회고
잘 되겠지..?
