오늘 적는 이 이야기도 최근에 한 것은 아니고 좀 됐는데 이제야 적는다..ㅋㅋㅠ
논의 배경
우리 BCSDLab이 운영하고 있는 서비스 코인에는 에브리타임과 비슷하게 시간표 서비스가 있다.
운영하고 있는 서비스를 보면 학교 강의 정보를 크롤링 해서 넣은 lecture 테이블과 학생들이 시간표로 추가한 정보를 갖고 있는 timetable 테이블이 있다. 해당 테이블 들을 보면 몇가지 문제점을 쉽게 알 수 있다.
문제점
- 우선 lecture 테이블이 갖고 있는 상당히 많은 정보(강의명, 학점, 담당교수, 등...)가 불 필요하게 timetable 테이블에 중복으로 저장 됨을 알 수 있다.
- 이와 연관된 문제로, lecture 테이블의 강의 정보가 변경되어도 timetable 테이블의 정보는 변경되지 않는 문제가 발생할 수 있다. 비록 이러한 일이 자주 발생하지는 않겠지만, 데이터의 일관성을 유지하는 데 문제가 있을 수 있다.
또한 위와 같은 구조로 서비스를 업데이트 및 개편하고 있는데 현재 구조로는 학기 별로 여러 시간표를 저장 만들 수 없다.
개선방안
따라서 위와 같이 테이블 구조를 정규화, 개편하기로 했다
간단해보이지만 정말 많은 고민을 하면서 테이블 구조를 개편했다.
우선 'timetable_lecture' 테이블이 'timetable_frame'(학기별로 있는 시간표 틀)과 'lecture'(학교 강의 정보)를 참조하여 중복 데이터를 최소화했다.
하지만 보면서 여전히 몇가지 속성이 중복되어 보인다고 생각할 수 있다.
이는 우리가 아래와 같이 커스텀 시간표로 개편하면서 학교 강의 정보가 아닌 개인 일정도 담을 수 있게 하기 위해 위와 같은 속성들을 넣었기 때문이다.
실제로는 중복되지 않는 다는 소리다.
지금 와서 생각해보니, null 값이 너무 많아져서 커스텀 시간표용 테이블을 따로 만드는 것도 고려했지만, 우리가 떠난 후 이 서비스를 운영할 후임자들과 서비스 로직 구조 개편의 복잡성을 생각하면 현재가 가장 현실적인 선택이었던 것 같다.
여전히 의문이 들 수 있다. 왜 timetable_lecture가 lecture와 frame을 참조하게 만들었으면서 외래 키(fk) 설정은 하지 않았는지 궁금할 수 있다. 이 역시 커스텀 시간표를 고려한 설계로, 만약 학교 강의가 아닌 개인 일정을 추가한다면 lecture와 timetable_lecture의 fk에는 null 값이 많이 들어가서 속도에 문제가 생길 것이라 판단했다.
이렇게 테이블 구조를 만들어서 반은 한 것인가..? 하는 생각이 들었지만 그것은 크나큰 오산이였다.
(시간표 서비스 개편(2)에서 계속..)
