6. DB 기초 작업 - DBMS 결정 + ERD 그리기

DBMS는 어떤 걸 써야 할까?

DB에 대해 생각할 때 가장 먼저 한 질문은, 과연 어떤 DBMS를 써야 할까에 대한 것이었다. 가장 먼저 한 질문은 classic한 RDBMS를 쓸 것인가, 아니면 MongoDB와 같은 NoSQL 기반의 DB를 써야 할까였다.

사실 이번 프로젝트에서는 NoSQL을 굳이 쓸 이유는 없다. 프로젝트에서 표현해야 할 데이터는 User, Post, Comment, Lecture, Alarm 등이 존재할 텐데 이는 전부 형식이 정해진 데이터이며 서로간의 관계로 표현이 가능한 것들이기 때문에 RDBMS로 충분히 나타낼 수 있기 때문이다. 따라서 굳이 NoSQL 말고 RDBMS를 쓰기로 결정하였다.

그렇다면, 과연 그 중 어떤 것을 쓸까? 예제를 보니 MySQL을 사용하는 예시가 많이 보였다. pip로 mysqlclient를 깔아서 아주 간단하게 연결할 수 있어 이에 대한 고민을 하지 않아도 된다. 그리고 Django의 ORM을 이용하는 것 역시 가능하다. 거기다가 오픈소스는 무료라, 일단 MySQL을 써 보기로 하였다.

ERD 그리기

그렇다면 이제 할 일은 테이블을 어떤 걸 짜고, 관계를 어떤 걸 만들지를 정해야 한다. 일단 지금까지 나온 기능을 볼 때, 무조건 들어가야 하는 데이터는 다음과 같은 것들을 뽑을 수 있다.

• User : 당연히 회원가입을 지원하는 커뮤니티이므로 필요하다. 권한은 사이트 관리자인 admin, 강사들이 쓰는 staff, 일반 User 세 단계로 나눠 놓을 예정이다.
• Post, Comment : 글과 댓글은 이 프로젝트의 핵심 요소이므로 반드시 필요하다.
• Lecture : 동영상 링크를 담은 데이터이다. 처음에는 따로 나누지 않고 Post를 사용하여 처리해 주고 싶었는데, 사용자 요구사항에 depth가 많이 추가되어 Post와 분리하여 따로 관리하는 것이 더 좋을 것 같았다.
• Alarm : 전에 api 편에서 알림 기능이 아예 빠져 버렸었다. User나 Post와 연동하여 알람을 보내 주는 기능을 넣을 것이기 때문에 필요하다.
• likes : 추천은 User와 User의 One-to-one relation으로 표현 가능하므로, DB에 추가해야 한다.

이제 이를 바탕으로 ERD를 직접 그려야 한다. created_at은 무조건 field로 전부 넣어 줄 예정이다. foreignkey는 id field를 추가하여 설정할 것이다. 그리기 도구로는 코드를 입력해서 자동으로 table을 시각화해 주는 dbdiagram.io 를 사용하였다. 각 table 간 field 설명과 relation 설명은 아래에 조금 더 자세히 남길 것이다.

• user : 로그인 시 입력할 ID를 나타내는 login_id를 비롯해 회원가입 때 입력하는 nickname, password 등의 정보가 들어 있다. 그리고 email은 인증 시 입력하는 이메일을 받고 role의 경우 admin, staff, common 세 단계로 구성되며 기본적으로 가입 시엔 common이다. staff는 인증된 user에 한해 직접 권한을 수정해 줄 예정이다.

• post : post에는 제목과 내용인 title과 content, 글쓴이의 id를 foreignKey로 가져오는 user_id와 정해진 enum type의 category가 있다. category의 세부 사항은 notice, free, korean_question, math_question, english_question, etc_question, korean_data, math_data, english_data, etc_data가 있다. 또한 content가 text로 되어 있는데, ckeditor 등의 에디터를 적용한다면 field가 바뀔 수도 있다.

• comment : comment에는 post와 비슷하게 content가 있고, 당연히 foreignkey로 어느 post에 속하는지 알려 주는 post_id와 어느 user가 썼는지를 나타내는 user_id를 명시해야 한다. 또한 대댓글을 명시하기 위해 부모 댓글이 있다면 이를 표시하는 parent_comment_id 역시 있어야 한다.

• lecture : 유튜브 링크를 통해 재생하므로 youtube_link field를 가져야 한다. 그리고 카테고리 분류를 위해 depth를 나누어서 category들을 만들었다. 가장 상위 수준을 1로 하고 거기 속하는 하위 수준의 카테고리를 따로 두었다. 만약 category field를 하나로 하면, 상위 분류의 카테고리의 강의를 한 번에 조회할 때 각 분류별로 전부 하드코딩으로 조건을 써 주어야 하기 때문이다. 따라서 카테고리를 나누어서 상위 분류의 카테고리와 하위 분류의 카테고리를 조회할 때 편하게 할 수 있도록 하였다. 대신 하위 카테고리가 존재하지 않는 lecture의 경우 null이 생기는 것을 감안하여야 한다.

• like : 추천을 나타낸다. 역시 foreign key로 어떤 게시물에 대한 추천인지 명시하기 위해 post_id를 가지고, 댓글에 달린 추천일 경우를 대비해 comment_id 필드도 있어야 한다. 이렇게 할 경우 null이 생긴다는 단점이 있다. 그리고 이들을 user와 이어 주는 user_id fk도 있어야 한다.

• alarm : 자신의 글에 댓글 등이 달리면 오는 알람을 나타내기 위한 테이블이다. 역시 user_id와 post_id, comment_id를 받아서 어느 글의 어느 댓글 때문에 알람이 오는지 명시해 주어야 한다. 그리고 알람의 내용을 표시하는 content 필드도 있다.

다음 목표

이제 ERD를 추가했으니 Django project를 만든 뒤 이를 이용하여 Django ORM을 통해 DB와 연결하여 실제로 테이블을 프로젝트에 연결해 보도록 할 예정이다. 드디어 실질적인 첫 코딩이 될 것 같다.