ERD 설계
모두의 게시판은 커뮤니티 게시판으로 유저(users)와 게시글(contents), 댓글(comments)을 메인 테이블로 구성하였다.
따라서, 초기 테이블 설계는 유저와 게시글, 댓글을 메인으로
유저에는 유저 이미지, 유저 역할이 하위로
게시글에는 게시글 이미지, 게시글 좋아요, 스크랩이 하위로
댓글에는 댓글 좋아요, 대댓글, 대댓글 좋아요가 하위로 테이블을 구성하였다.
이러한 테이블 설계는 초기 백엔드 멤버가 3인으로 구성되었기 때문에 테이블을 3:4:4 단위로 고른 역할 분배를 할 수 있다는 장점이 있었기 때문에 다음과 같이 테이블을 설계하였다.
따라서 각 구성원들은 유저, 게시글, 댓글 단위로 역할을 분담하여 테이블을 설계 및 구현하였다.
테이블 설명
users
- 유저 정보를 저장하는 테이블이다.
users (
user_id bigint PK, // userId값
created_at datetime, // user가 가입한 시간
last_modified_at datetime, // user를 수정한 시간
active_status varchar(255), // user 활동 상태(enum타입으로 받고 string으로 저장) / 활성, 비활성, 휴면 계정을 구분한다.
auth_provider varchar(255), // local 또는 ouath로 가입한 경우를 구분하기 위해 만들어졌다.
email varchar(255), // email 주소
login_type varchar(255), // 더미데이터(ouath가입자를 구분하기 위해 만들었다)
nickname varchar(255), // user name
password varchar(255), // user 비밀번호
profile_key varchar(255), // 더미데이터(사용중이지 않음)
profile_url varchar(255), // user profile 이미지 주소
)
user_roles
- ADMIN과 USER 역할을 저장하는 테이블
user_roles (
user_id bigint PK, // userId값
roles varchar(255), // user 역할 / user와 admin이 있음
)
user_images
- USER PROFILE 이미지를 저장하는 테이블
user_image (
user_image_id bigint PK, // userImageId값
user_id bigint FK, // userId 값
user_image_url varchar(255), // S3에 담긴 user image url 주소값을 저장
)
contents
- contents 정보를 저장하는 테이블
contents (
content_id bigint PK, // contentId
created_at datetime, // 게시글 등록 시간
last_modified_at datetime, // 게시글 수정 시간
category varchar(255), // 카테고리 분류 (ex: 뷰티, 자유게시판) / enum으로 저장
content varchar(255), // 게시글 내용
content_heart_count bigint, // 게시글 좋아요 수
title varchar(255), // 게시글 제목
view_count bigint, // 게시글 조회수
user_id bigint, // 게시글을 등록한 userId
)
content_heart
- 게시글 좋아요 정보를 저장하는 테이블
content_heart (
content_heart_id bigint PK, // contentHeartId
created_at datetime, // 게시글 좋아요 생성 시간
last_modified_at datetime, // 게시글 좋아요 수정 시간(더미데이터)
heart_type varchar(255), // 게시글 좋아요가 post 됐을 때 활성화 (enum타입이며 add,remove로 구성)
content_id bigint, // 좋아요를 누른 게시글 contentId
user_id bigint // 좋아요를 누른 userId
)
- heart_type은 contentHeart가 post될 때 활성화되며 한번 더 post되면 remove된다.
content_image
- 게시글 이미지를 저장하는 테이블
content_image (
content_image_id bigint PK, // contentImageId값
content_id bigint FK, // contentId 값
content_image_url varchar(255), // S3에 담긴 content image url 주소값을 저장
)
scraps
- 특정 USER가 스크랩한 게시글을 저장하는 테이블
scraps (
scrap_id bigint AI PK, // scrapI
created_at datetime, // 스크랩 생성 시간
last_modified_at datetime, // 스크랩 수정 시간 (더미데이터)
scrap_type varchar(255), // 게시글을 post한 경우 add 또다시 post한 경우 remove처리됨
content_id bigint, // 스크랩한 게시글 contentId
user_id bigint // 스크랩한 userId
)
comments
- 댓글 정보를 저장하는 테이블
comments (
comment_id bigint AI PK, // commtentId
created_at datetime, // 댓글 생성 시간
last_modified_at datetime, // 댓글 수정 시간
comment varchar(255), // 댓글 내용
comment_heart_count bigint, // 댓글 좋아요 수
content_id bigint, // 댓글단 게시글 contentId
user_id bigint // 댓글단 userId
)
comment_heart
- 댓글 좋아요 정보를 저장하는 테이블
comment_heart (
comment_heart_id bigint PK, // commentHeartId
created_at datetime, // 댓글 좋아요 생성 시간
last_modified_at datetime, // 댓글 좋아요 수정 시간(더미데이터)
heart_type varchar(255), // 댓글 좋아요가 post 됐을 때 활성화 (enum타입이며 add,remove로 구성)
content_id bigint, // contentId
user_id bigint // userId
)
replies
- 대댓글 정보를 저장하는 테이블
reply_heart (
reply_id bigint PK, // replyId
created_at datetime, // 대댓글 생성 시간
last_modified_at datetime, // 대댓글 수정 시간(더미데이터)
reply varchar(255), // 대댓글 내용
reply_heart_count bigint, // 대댓글 좋아요 수
comment_id bigint, // 대댓글단 게시글 commentId
content_id bigint, // 대댓글단 게시글 contentId
user_id bigint // 대댓글단 userId
)
reply_heart
- 대댓글 좋아요 정보를 저장하는 테이블
reply_heart (
reply_heart_id bigint PK, // replyHeartId
created_at datetime, // 대댓글 좋아요 생성 시간
last_modified_at datetime, // 대댓글 좋아요 수정 시간(더미데이터)
heart_type varchar(255), // 대댓글 좋아요가 post 됐을 때 활성화 (enum타입이며 add,remove로 구성)
comment_id bigint, // 대댓글 좋아요를 누른 댓글의 commentId
reply_id bigint, // 대댓글 좋아요를 누른 replyId
user_id bigint // 대댓글 좋아요를 누른 userId
)
ERD 설계를 마치며
ERD 설계는 내가 구현하고자 하는 서비스의 틀을 만드는 단계로, 아주 중요한 부분이라고 할 수 있다. 이전 가치갈래 프로젝트의 경우에는 ERD설계를 충분하게 고려하지 않고 프로젝트를 진행하였더니 추 후에 여러 연관관계가 서로 얽혀 코드 순환참조가 발생하였다.
반면에 모두의 게시판을 설계하는 단계에서는 애자일로 프로젝트를 진행한다고 하더라도 서로 순환참조가 발생하지 않기 위해서 최대한 테이블간에 연관관계를 단순하게 구성하고자 하였다.
또한 테이블의 이름 하나 하나를 고민하여 어떤 사람이 보더라도 "이 기능이 어떤 기능을 하겠구나"라는 것을 유추할 수 있도록 설계하였다.
최종적으로, 개발 초기 백엔드 개발자 2명이 취업으로 이탈하였음에도 불구하고 내가 다른 멤버의 코드를 이어서 작성할 때 아무런 어려움 없이 프로젝트를 개발할 수 있었다.
'Project > 모두의 게시판' 카테고리의 다른 글
[Every-Board] 프로젝트 개요 (0) | 2023.06.27 |
---|