순수웨딩 프로젝트에서 두개의 테이블을 단일 테이블로 합쳤습니다. 하지만, 플래너의 비율이 예비부부보다 확연히 적고 이후 서비스의 유지보수 관점에서는 좋지 않았던 선택이었던 것 같습니다.
서론
지난 카카오 테크 캠퍼스 3단계, 순수웨딩 프로젝트에서 유저 테이블은 플래너와 예비부부 2개로 시작했고 이후 중복의 최소화라는 큰 세계관 안에서 이를 단일 테이블로 변경하였습니다. 하지만, 여러 관점에서 바라보았을 때 이 선택이 좋은 선택이었을지 고민을 해보았습니다.
본론
단일 테이블 전략?
물리적으로 하나의 테이블을 이용하고, 구분시킬 하나의 필드를 통해 논리적으로 두개의 테이블을 만드는 느낌입니다. 순수웨딩 프로젝트에서 최초에는 플래너, 예비부부 2개의 테이블이 존재했지만 '중복 최소화'라는 관점에서 이를 하나로 통합시켰습니다.
하지만 이는 데이터 비율이 극명하게 차이가 나면 비효율적일 수도 있습니다. 물론 인덱스를 이용하면 큰 차이는 없겠지만, 일단은 차이가 날 것입니다. 예를 들어, 플래너의 비율이 압도적으로 적다면, 소수의 레코드를 조회하기 위해 많은 자원을 소비해야하는 경우가 발생할 수도 있기 때문입니다. 이러한 관점에서 단일 테이블 전략이 좋은 선택이 아닐 수 있습니다.
또한, 이후에 플래너 혹은 예비 부부만 해당되는 필드가 필요하게 된다면? 이때는 어떻게 처리하는게 좋을지에 대해서도 좋은 선택이 아닐 수 있습니다.
이런 의문에서 시작된, 여러 전략들입니다.
전략 1. 다시 분리하자
원래대로 롤백하여 두개의 테이블을 만들어 관리하는 방법입니다. 필요한 테이블에서 필요에 맞게 조회를 하거나 속성의 추가/삭제가 가능합니다. 데이터의 분포가 확연히 차이가 난다면 이 전략이 좋을 것 같다고 생각됩니다.
전략 2. 단일 테이블 유지, 새로운 추가 테이블
우선 만들어진 테이블은 그대로 두고, 속성을 추가해야 한다면 테이블을 새로 만들어 관계를 맺어주는 방법입니다. join을 해서 필요에 따라 가져오면 되기 때문에, 스키마의 큰 변형 없이 유지할 수 있는 방법입니다. 조회의 문제는 인덱스를 부여하여 해결하면 될 것 같습니다.
전략 3. 그냥 테이블에 추가하고, 필요 없으면 null
테이블에 속성을 추가하고, 플래너 혹은 예비부부에서 필요하지 않는 값이라면 null을 추가하도록 데이터베이스 및 서비스 로직에 제약조건을 추가합니다. 이것도 스키마의 큰 변형이 없을 것 같아서 좋은 방법인 것 같습니다. 이 경우에도 인덱스를 통해 조회 문제를 해결하면 될 것 같습니다.
결론
순수웨딩 프로젝트에서는, 플래너의 비율이 예비부부의 비율보다 확실히 적을 것입니다. 활성화되어 이용자가 많아진다면, 매년 꾸준히 증가하는 예비부부의 숫자보다 당연히 플래너의 증가 숫자가 적을 것이기 때문에 조회의 관점에서 바라볼 때 1번 전략이 좋을 것 같다고 느껴집니다. 하지만 스키마 변형이 어렵다면, 2번 전략이 좋게 느껴지는 것 같습니다.
회고?
데이터베이스 과목을 수강하면서 느낀 지난 프로젝트에 대한 회고에 가까운 글 입니다... 좀 더 빨리 이론적으로 많은 것을 배우고 프로젝트를 했으면 더 좋았을 것 같다는 생각이 들었습니다. 카카오 테크 캠퍼스의 1단계 학습 기간이 학기 중과 겹쳐서 병행하기 너무 어려웠는데, 필요한 지식을 3단계가 끝나고 자세히 배워서 설계와 구현 단계에서 했어야 할 고민들을 너무 늦게 했습니다.
이번에 알았으니! 다음 프로젝트에서는 이를 적용해서 이후 유지보수 관점에서도 바라보면서 데이터베이스 스키마를 설계해야겠습니다! 이상 끝-
