모든 서비스 개발의 가장 기본이자, 중요한 부분이다!
그 이유는 도중에 바뀔 수 없으며, 이를 바탕으로 데이터 작업이 이뤄지는 만큼 설계가 틀어지는 일은 없어야 한다.
그럼 시작해보자!
1. DB 선택
사용하는 DB로는 Mysql을 사용해 볼 것이다.
비교적 간단한 데이터 작업이 이뤄질 것이므로, 뭘 써도 상관없다고 생각했다. 따라서 가장 익숙한 DB를 사용하기로 했다.
2. 개념 생각해보기
기본적으로 어떤 개념들이 필요할지 생각해보자.
우선 블로그의 목적은 나의 일상이나 소개하고 싶은 것들을 "나만의 사이트를 통해 온라인으로 기록하고 소통"할 수 있어야 한다는 것이다.
기본적으로 내 글을 담아내기 위해서는 카테고리와 포스트가 필수이다.
관리자는 따로 존재하지 않고 서비스 사용자는 나 뿐이므로, USER는 생각하지 않기로 한다.
소통의 방법으로는 댓글이 있을텐데, 이는 disqus라는 외부 API를 통해 구현할 것이니, 역시 댓글도 고민할 필요가 없다.
그럼 카테고리와 포스트로 좁혀졌는데, 포스트에는 파일, 이미지 등을 올릴 수 있어야 한다. 따라서 업로드 파일도 필요하다.
그리고 각 페이지마다 배경도 필요하므로, 배경 이미지도 필요하다.
결과적으로 필요한 개념들은 다음과 같다.
- CATEGORY들
- POST
- 업로드 파일
- 배경 이미지
3. 테이블 구체화
각 개념들끼리 어떤 관계를 지니는지 생각해봐야 하지만, 너무 직관적인 구조라 건너 뛰도록 하겠다.
일단은 카테고리-포스트-파일은 수직적인 참조 구조이므로, 참조 관계로 엮어내면 될 것 같다.
(말은 간단하지만, 사실 미친 짓이다...블로그 구조를 바꿔야 할지도..)
-
각 카테고리 테이블들은 별다른 역할이 없다.
하위 개념들을 묶어주기 위한 용도일 뿐이므로, 배경 이미지인 "이름"과 어떤 카테고리인지 설명해 줄 "설명글"로 충분하다. -
포스트 테이블은 다양한 내용이 들어갈 수 있는 테이블이다.
공유, 좋아요, 태그 등 원한다면 얼마든지 들어갈 수 있다.
지금이야 구조가 간단하니 상관없지만, 그래도 염두해두고 설계하자.
우리는 심플을 추구하므로, "제목"과 글을 저장할 "컨텐츠"만 있으면 된다. 언제 만들었는지인 생성/수정 시간"은 필수이고, 올라갈 이미지/파일들은 FILE 테이블을 참조하면 된다. -
그다음으론 업로드 테이블과 배경 테이블인데, 이 둘은 하나의 "FILE 테이블에 보관"하되, 사용의 편의를 위해 각각 참조 테이블을 만들었다.
-
업로드 테이블은 말 그대로 포스트의 파일을 말하며,
각 파일 종류를 DATA_TYPE으로 구분하여 저장하는 방식을 선택했다. -
마지막으로 배경 테이블이다.
페이지의 배경 이미지를 담당하며 DATA_TYPE는 없고,
FILE, 카테고리, 포스트와 참조관계만을 가지고 있다.
이상으로 간략히 테이블들을 생각해봤는데, 이를 무작정 엮어버린다면 다음과 같은 관계도가 나온다.
3. 결론
제법 끔찍한 구조가 나왔다..ㅇㅁㅇ;;
파일~테마까지 사실상 일방적인 수직 참조 구조를 하고 있다.
그리고 배경 테이블이 무려 5곳이나 참조하고 있다.
자주 쓰이는 "메인 테이블"이 아닌데도 저렇게 많은 참조를 하고 있는 것이 매우 보기 안 좋다.
배경 테이블은 쪼개서 관리한다 치지만, 문제는 카테고리이다.
카테고리의 참조 관계는 너무 당연한 것이라, 답이 없을 듯 한데...
아마 블로그 카테고리 구조 자체를 바꿔야하지 않을까 싶다.
어떻게 할지 좀더 고민해보고 2차를 올리도록 하겠다.
그럼 이만!
99. 부록
해당 다이어그램을 그리는데는 https://dbdiagram.io/ 라는 사이트를 이용했다.
코드를 작성하고 바로바로 결과를 볼 수 있어서 유용한 사이트이다. 굿굿!
