앞서 작성한 API 문서를 토대로, 가능한 효율적으로 데이터베이스 테이블을 구성하겠습니다.
구성도는 ERDCloud에서 작성했습니다. 그리고 이미 작성 해놨습니다.
설계된 구성을 먼저 보여드리고 하나씩 살펴보도록 하겠습니다.
카테고리 테이블 (category)
카테고리 관련하여
1. 카테고리 이름만 담은 목록을 요청
2. 카테고리의 모든 정보를 담은 목록을 요청
3. 새로운 카테고리 정보를 반영하는 요청
세 가지 요청이 있었습니다.
따라서 이름 필드는 당연히 있어야 합니다.
관리자에선 카테고리의 순서를 마음대로 막 바꾸거나 새로 추가하거나 삭제하는 등
거의 새로운 카테고리 목록을 구성하여 서버에 반영합니다.
순서나 이름이 바뀌어도 각 카테고리의 identity는 유지 되어야 합니다. 따라서 고유ID 필드를 두고, 순서나 이름이 바뀌어도 ID는 건드리지 않도록 로직을 짜면 됩니다.
또한 해당 카테고리에 속한 컨텐츠들은 카테고리의 이름이 바뀌어도 여전히 그 카테고리 소속일 수 있도록, 카테고리의 이름이 아닌 고유ID를 컨텐츠 테이블에서 외래키로 가집니다.
컨텐츠 테이블 (content)
내용 필드에는 길고 긴 문자열이 들어갈 겁니다. 마크다운 문법으로 작성 된 문자열이고, 클라이언트에선 이 텍스트를 받아서 HTML로 파싱 후 화면에 그릴 겁니다. 따라서 내용 필드의 타입은 BLOB(LONG)이 되어야 합니다.
썸네일 필드엔 업로드한 이미지들 중 첫 번째 이미지의 경로가 들어갑니다.
방문기록 테이블 (visit)
프론트 단에서 필요한 방문기록 종류는
1. 총 방문자 수
2. 월별 방문자 수
3. 오늘 방문자 수
세 가지입니다.
년월과 일을 구분하여 저장하면 group by키워드로 월별 방문자도 쉽게 구할 수 있습니다.
방문자 테이블 (visit)
방문자의 IP를 저장하여 동일 IP로 방문 시 방문 기록을 UPDATE하지 않습니다.
매일 자정에 TRUNCATE로 초기화 하여, 다음날 최초 접속 시 다시 기록되게 합니다.
따봉기록 테이블 (like)
누른 사람의 IP와 컨텐츠 ID를 저장하여, 여러 번 눌러도 한 번만 따봉이 올라가게 합니다.
이미지경로 테이블 (img)
컨텐츠 작성 중 이미지를 따로 업로드 합니다.
업로드한 이미지 경로를 저장하는건 쉬운데, 어느 컨텐츠에 들어간 이미지인지 CID를 넣어 주는 과정은 고민이 필요합니다.
업로드 된 이미지는 우선 CID를 -1로 넣어 두고, 업로드 된 컨텐츠 정보가 DB에 잘 들어가면 그 때 CID를 UPDATE하겠습니다.
이제 서버 개발을 위한 준비는 얼추 되었습니다. 원래는 이 다음에 전체 시스템 구조를 그려보려고 했는데, 딱히 구조를 그릴만큼 거창하지가 않습니다.
클라이언트 - 프론트서버 - 백엔드서버 - 데이터베이스
너무 간단한 구조에요.
따라서 이제부터 본격적으로 백엔드 서버를 제작해 보겠습니다.
