- 공통 사항 : 회원에 관련된 정보들은 항상 where절에서 '회원KEY = '로 조회하기 때문에, 각각의 테이블 안에서 unique한 키가 따로 존재할지라도 첫번째 PK로 회원KEY를 설정하여 조회 성능을 높이는 전략을 선택하였다.
- 일반 회원과 관리자는 필요한 정보와 사이트 사용 방식이 다르므로 다른 테이블로 설계하였다.
- 배송지의 경우 자주 변경될 수 있으므로 수정, 삭제 가능한 리스트로 관리하고, 주문시의 배송을 항상 기록하는 구조
- 기본 배송지의 경우,
- 배송지 테이블에 기본인지 아닌지 명시
- 교차 테이블 두기
- 회원에 기록하기
- 세 가지 선택지 중에 과정과 구조의 간단함, 편의성을 고려하여 마지막 것을 선택하였다.
- 적립금 등에 관한 통합 테이블로 관리
- 적립, 사용, 취소
- 테이블 3개로, 2개로, 1개로 관리하는 경우를 고려하였다.
- 테이블을 쪼개었을 때 중복이 줄거나 구분이 명확해지는 이점이 특별히 있지 않았기 때문에 한 개로 관리하도록 하였다.
- 등록일은 row가 등록된 모든 날짜이며 금액을 +/-로 구분하여 입력 가능하도록 하였고, 잔액을 따로 표기하여 한 개의 적립에 대한 만료 처리가 가능하도록 설계하였다.
- 화폐 종류, 적립/적립취소/사용/사용취소/만료에 대한 구분 코드, 구매/이벤트/충전/취소/만료에 대한 사유 코드를 각기 따로 두어 체계적인 관리가 가능하도록 하였다.
- 총 금액에 관한 정보는 절대 틀어져서는 안 되는 중요한 정보이기 때문에 정규화하고 계산하는 방식을 선택했다.
- 쿠폰의 조건은 크게 금액 조건과 사용 대상 조건으로 나뉜다. 사용 대상에 대한 조건은 총 금액/배송비/특정 카테고리처럼 다양한 케이스가 존재할 것이다. 또한 어떤 한 종류의 쿠폰과 다른 종류의 쿠폰이 제한하는 사용 대상의 종류는 같을 때도 많다.
- 따라서 쿠폰 사용 대상이라는 하나의 테이블을 만들어 대상 조건을 묶음으로 설정할 수 있도록 설계하였다.
- 또한 하나의 사용 대상 종류에는 여러 개의 카테고리가 포함될 수 있으므로 교차테이블을 통해 연관관계를 가질 수 있도록 하였다.
- 발급할 쿠폰에 대한 계획이 먼저 존재할 것이며, 같은 쿠폰을 여러 회원이 발급 받을 것이므로 원본 쿠폰 테이블을 만들고, 원본 쿠폰의 PK를 개별 회원의 개별 쿠폰 테이블이 참조할 수 있도록 설계하였다.
- 쿠폰에 대하여는 사용된 주문과 연결하여 이력이 남을 수 있도록 하였고, 쿠폰의 다양한 상태 또한 관리될 수 있게 하였다.
-
스스로 잘하기, 항상 배우기, 함께 가기
- 단순 작업이 많아서 재미 없는 부분이라 생각하고 있었는데, 얼마나 깊이 파느냐에 따라 달라질 수 있었다. 어쩌면 이해가 부족했기 때문에 재미가 없었을지도 모른다. 그간의 태도를 반성하게 되었고, 꼼꼼한 반복 작업 자체에 대한 생각도 많이 바뀌었다.
- DB튜닝에 대한 부분을 배우고 데이터 모델링을 해보니 코드로 i/o할 때의 필요성이나 편리함만이 아니라 성능도 고려한 설계에 대해 많이 고민할 수 있어서 재밌었다.
- 여러 동기들에게 찾아가서 작업물에 대해 물어보고 설명도 들었는데, 새로운 인사이트를 얻을 수 있었고 서로 질문을 주고 받는 과정이 정말 즐거웠다.
-
체계적 정리에 대한 필요성
- 기초 단계에서 꼼꼼해야 한다 : 나중에 뒤엎는 것은 너무 비용이 많이 든다! 초기 단계에서 최대한 놓치는 것이 없게 하기 위해서는 정의 단계부터 시뮬레이션까지 꼼꼼한 작업이 필요하다.
- 소통에 필요하다 : erd 이외의 정리된 자료가 소통에 큰 도움이 되었다. 복잡한 내용을 다룰 수록 다른 형태의 간단한 자료가 필요했다. 고민한 내용에 대해서도 설명할 때는 그림을 그리거나 더미 데이터를 보여주며 설명하는 쪽이 설명과 이해가 쉬웠다.
- 구현과 운영까지 가기 전 설계에서 끝났기 때문에 결국 생각한 설계가 맞았는지 검증하기는 어려웠다. 생각한 구조가 맞았을까? 좋은 개발자가 되기 위해 앞으로도 쭉 고민해야 하는 부분일 것 같다.
- 정규화 vs 역정규화
- PK 설정
- FK와 관계 설정
- 구조