DB Schema
"DB table 을 2 개로 압축한 이유" 에 대한 답변을 발표 영상에 담게 되었습니다. 오늘은 아이디어를 정리하는 차원에서 블로깅을 진행하려고 합니다.
처음에 구상했던 DB Schema 는 사실 위의 이미지와는 많이 달랐습니다. 좋아요에 관한 정보라든가, 재료, 태그 등을 다 따로 나누어 분류할 계획이었죠. 테이블의 개수도 족히 8개 이상은 되었던 것 같고, 다대다 테이블도 아주 많았습니다.
기획을 마치고 엔지니어의 피드백을 받으면서, DB를 압축해서 2 개로 가보자는 조언을 들었습니다. 여러 개의 다대다 테이블로 나누어놓았던 게시물에 관한 데이터들을, article 테이블 안의 개별적인 column 으로 압축시키자는 아이디어였는데요. 핵심은 배열을 문자열로 변환해 저장하는 것에 있습니다. JSON.stringify 를 이용해 배열을 문자열로 변환하고 DB 에 저장해두었다가, 클라이언트의 요청이 있을 때 다시 원래의 배열로 변환해 전달하는 것이죠.
장점
테이블을 2 개로만 압축해 진행할 때의 장점은 생산성, 최적화 이 두 가지로 정리할 수 있을 것 같습니다. (사실 그 이상을 알아내기에는 아직 내공이 모자란 듯 합니다)
먼저 압도적으로 향상된 생산성입니다. 기본적으로 게시물에 관한 모든 정보는 article 테이블에 들어있기 때문에 다른 테이블을 신경쓰지 않아도 됩니다. 또한 애초에 배열인 데이터를 문자열로 변환하기만 해서 저장한 것이기 때문에, 클라이언트에 다시 데이터를 전달할 때에도 배열 그 자체를 전달하면 충분합니다. 코드가 복잡해질 이유가 없는 셈이죠.
비슷한 이유에서 서버의 최적화에 크게 도움이 됩니다. 게시글에 관한 정보가 여러 개의 테이블에 나누어져 있다고 가정해보겠습니다. 이 경우 서버는 클라이언트가 전달해준 데이터를 여러 개의 테이블에 나누어 저장해야 합니다. 클라이언트의 요청에 따라 데이터를 돌려줘야 할 때도, 기본적으로 여러 개의 테이블에서 필요한 정보를 조회해야 합니다. 조회할 뿐 아니라 필요한 경우 이를 다시 재배치를 해야할 수도 있겠죠.
하지만 게시글에 필요한 모든 데이터가 article 이라는 테이블에 정리되어 있다면 서버가 DB 를 조회하는데 들어가는 자원의 양도 상대적으로 낮아집니다. 물론 프로젝트 차원에서 이 차이는 크게 두드러지는 것은 아닐 수 있지만, DB 에서 운용해야 하는 데이터의 양이 늘어날 수록 이 차이는 커지겠죠.
공부해야 할 것
관계형 데이터베이스를 다룰 때의 효율에 관해서는 공부해야 할 것이 더 있는 것으로 알고 있습니다. 구글링을 통해 여러 정보를 접할 수 있었는데 지금 수준에서는 이해하기 어려운 내용들이었습니다. 아직 검색 능력이 부족한 탓인지 자꾸 논문 자료들이 뜨네요.
처음 프로그래밍을 배우면서는 등장하는 모든 개념을 다 이해하려고 하다가 오히려 학습 속도가 더뎌지곤 했었는데, 지금은 그렇게 하지는 않습니다. 경험치가 쌓여갈수록 차츰 더 깊은 것을 배울 수 있을거라고 생각하게 되었거든요.
검색했던 자료 중에서 쿼리 최적화에 관해 조금 더 이해하는 데 도움을 받았던 블로그 글을 하나 링크합니다.
outro
답변하는데 주어진 시간은 1분 남짓입니다. 위의 내용을 정리해서 답변해볼 계획입니다. 그 외에도 개인 발표 영상을 준비해야 합니다. 블로깅했던 내용들을 돌아보면서 주말 동안은 개인 발표를 준비해야겠습니다.
