소설을 관리하는 테이블


하나의 소설 시리즈에는 여러 개의 회차가 존재할 수 있고, 각 회차에는 몇 십에서 몇 백 페이지 되는 내용이 존재한다. 보통 소설은 한 페이지 당 글자 수가 200자 정도 된다고 한다.

웹 소설의 특징상 모바일 화면으로 많이 보기 때문에 실제 책보다 더 큰 글씨로 담아야 하기 때문에 적당한 길이로 글자 수를 제한하여야 한다.

1차 DB 설계


1차적으로 소설이라는 도메인은 삽입과 수정의 영역보다 조회가 더 중요한 도메인이라고 생각했다. 그리고 그 생각은 지금도 변함이 없다.

Untitled

다음과 같이 소설 테이블을 정의해보았다. 하지만 위 테이블의 문제점은 선호작을 불러올 때 마지막 페이지를 조회할 수 없다. 그 이유는 소설의 내용을 하나의 컬럼으로 관리하기 때문에 페이지를 나누는 게 쉽지 않은 작업이었다.

2차 DB 설계


빠른 조회를 위해 과감히 비정규화를 시도해봤다.

Untitled

굉장히 어지럽다. 컬럼이 많아졌고, 비정규화로 인해 조회속도를 향상 되겠지만, 데이터의 정합성이 매우 떨어질 거 같아서, 설계만 해보았다. 결과적으로는 별로 좋지 않은 선택같았다.

추가적으로 조회 시의 성능도 중요하지만, 데이터의 정합성 역시 무시하면 안된다. 특히나 소설은 하나의 소설에 여러가지 에피소드들이 있고, 해당 에피소드들에 여러가지 페이지가 존재하기 때문에 이 부분이 하나라도 잘못된다면 쉽게 꼬일 수 있다.

또한 하나의 소설에는 많아봤자 200~300개의 페이지가 존재한다. 그리고 사용자는 한번에 하나의 에피소드만 조회할 수 있기 때문에 조회하는 데이터가 그렇게 많지는 않다.

이를 바탕으로 다시 테이블 설계를 진행했다.