[프로젝트 설계] ERD 설계
주말의 집은 듀얼 라이프에 관심있는 사람들간의 소통의 장을 마련해주기 위한 서비스로, 커뮤니티 성격이 강한 서비스입니다.
주말의 집이 제공하는 커뮤니티는 자유 게시판, 홍보 게시판, 소개 게시판 총 3가지가 있습니다.
- 자유 게시판
일반 유저가 익명으로 자유롭게 게시글을 작성/수정/조회/삭제할 수 있다.
관리자 유저가 컴플레인 들어온 게시글에 대해 비공개(혹은 삭제) 처리할 수 있다.
게시글에 대해서는 임시 저장이 가능하다.
게시글 전체 리스트 조회 시, 말머리를 통해 필터링이 가능하다. ( 여기서 말머리는 게시글을 대표하는 키워드를 의미한다. )
게시글은 작성자 본인과 관리자만이 수정 혹은 삭제할 수 있다.
게시글에는 댓글을 작성할 수 있다. ( 단, 대댓글 기능은 지원하지 않는다. )
- 홍보 게시판
일반 유저가 익명으로 자유롭게 게시글을 작성/수정/조회/삭제할 수 있다.
관리자 유저가 컴플레인 들어온 게시글에 대해 비공개(혹은 삭제) 처리할 수 있다.
게시글에 대해서는 임시 저장이 가능하다.
일반 유저로부터 상단 고정 요청이 들어오면, 관리자는 해당 게시글을 상단에 고정시킬 수 있다.
상단 고정 개수( 기본 값 5개 )를 넘어선 후에 들어오는 상단 고정 요청을 처리하기 위해 관리자는 오래된 상단 고정 게시글을 고정 해제할 수 있다.
게시글 전체 리스트 조회 시, 말머리를 통해 필터링이 가능하다.
게시글은 작성자 본인과 관리자만이 수정 혹은 삭제할 수 있다.
게시글에는 댓글을 작성할 수 있다. ( 단, 대댓글 기능은 지원하지 않는다. )
게시글에는 좋아요 기능이 있다. ( 좋아요 개수를 통해 인기순 정렬을 지원한다. )
- 소개 게시판
관리자 유저만이 게시글을 작성/수정/삭제할 수 있다.
게시글에 대해서는 임시 저장이 가능하다.
일반 유저는 게시글을 조회할 수 있다.
게시글 전체 리스트 조회 시, 말머리를 통해 필터링이 가능하다.
게시글은 관리자라면 수정 혹은 삭제할 수 있다.
게시글에는 모든 유저가 댓글을 작성할 수 있다. ( 단, 대댓글 기능은 지원하지 않는다. )
게시글에는 좋아요 기능이 있다.
3가지 게시판 모두 공통적인 속성으로 [제목, 내용, 이미지, 작성자, 임시저장여부, 댓글]을 갖습니다.
자유 게시판과 홍보 게시판의 경우, 일반 사용자에게도 작성 권한이 있지만, 소개 게시판의 경우에는 관리자만이 작성 권한이 있습니다.
홍보 게시판의 경우, 게시글을 상단에 고정시킬 수 있어 고정 여부와 고정일시의 데이터를 추가로 필요로 합니다.
홍보 게시판과 소개 게시판에는 좋아요 기능이 들어가지만, 자유 게시판의 경우에는 좋아요 기능이 없습니다.
커뮤니티 성격이 강한 서비스이기 때문에 기획의 변경에 유연하게 대응하고자 각 커뮤니티 별로 테이블을 분리하여 관리하기로 결정하였습니다.
- ERD 초안
사용자( 사용자ID, 닉네임, 전화번호, 이메일주소, 비밀번호, 권한[일반, 관리자], 생성일시, 수정일시 )
자유게시판( 게시글ID, 제목, 내용, 이미지주소, 말머리, 임시저장여부, 작성자, 댓글, 생성일시, 수정일시 )
홍보게시판( 게시글ID, 제목, 내용, 이미지주소, 말머리, 임시저장여부, 작성자, 좋아요, 댓글, 상단고정여부, 고정일시, 생성일시, 수정일시 )
소개게시판( 게시글ID, 제목, 내용, 이미지주소, 말머리, 임시저장여부, 작성자, 좋아요, 댓글, 생성일시, 수정일시 )
댓글 ( 댓글ID, 내용, 게시글ID, 작성자ID, 생성일시, 수정일시 )
좋아요 ( 좋아요ID, 게시글ID, 작성자ID, 생성일시, 수정일시 )
ERD 초안을 바탕으로 Kotlin 코드로 옮기는 과정에서 기능의 변경이 생겼습니다.
- 사용자 테이블에 [가입경로, 연령대] 데이터 추가
- hard delete -> soft delete 방식으로 변경
- html 코드 데이터에서 value 추출
기획팀으로부터 회원가입 시, 사용자로부터 [가입경로, 연령대] 데이터를 추가로 받기를 원해서 테이블에 해당 컬럼이 추가되었습니다.
delete 방식의 변경은 개발팀에서 제안한 아이디어로, 요구사항의 변경에 유연하게 대응하기 위해서 데이터를 DB에서 완전히 삭제하는 것이 아닌 soft delete 방식으로 유저에게 노출되지 않도록 하는 것을 제안하였습니다.
프론트엔드 측에서 사용자가 작성한 게시글 내용을 HTML 코드 형식으로 백엔드에 넘겨줍니다. 이러한 방식을 사용하는 이유는 게시글을 작성할 때, 정해진 템플릿이 없기 때문에 게시글 내용에 대해서는 온전히 사용자가 디자인하기 나름입니다. 백엔드 측에서는 HTML 코드 형식으로 넘어오는 데이터에서 게시글 내용에 해당하는 value만을 추출하여 관리해야 했습니다. 이 추출 방식으로 2가지를 떠올렸습니다.
- select 시, DB에 사용자 정의 함수를 만들어 HTML 코드 파싱하기
- insert 하기 직전, 서비스 계층에서 HTML 코드 파싱한 value를 DB에 저장하기
1번의 방법을 적용했을 때 select( 단순 조회 혹은 검색으로 인한 조회 )가 가장 빈번하게 이루어질 것으로 예상되는데, 사용자 정의 함수까지 거쳐서 가공된 데이터를 조회하는 것이 성능상 이점이 될 수 없다고 판단하였습니다. 따라서 2번 방식으로 적용하였습니다. 2번 방식의 경우, JPA에서 지원하는 기본 내장 함수를 통해 조회 쿼리를 사용할 수 있습니다.
앞선 기능 변경까지 적용하여 Kotlin 코드로 옮긴 뒤, API 개발이 80% 진행된 시점에서 ERD 재설계를 제안하였습니다. 제안 이유는 아래와 같습니다.
- 중복 코드 발생
- 코드 관리의 어려움
ERD 설계 당시 가장 크게 초점을 둔 부분은 "테이블 구조의 잦은 변경이 발생하지 않도록 각 커뮤니티 별로 관리하는 것"이었습니다. API 개발을 진행하면서 중복되는 코드가 많아지고 같은 기능을 수행하는 함수들이 많아지면서 오히려 관리의 어려움이 발생될 것이 우려되었습니다.
테스트 코드 작성을 통해 API 명세서를 발행하고 있는데, API 개수가 많아짐에 따라 테스트 코드 역시 많아지고 기능 혹은 테이블 변경으로 인해 관리해야 하는 코드 수가 늘어났습니다.
이에 커뮤니티 테이블을 하나의 테이블로 관리할 것을 제안하였습니다.
- ERD 초안
사용자( 사용자ID, 닉네임, 전화번호, 이메일주소, 비밀번호, 권한[일반, 관리자], 연령대, 가입경로ID, 생성일시, 수정일시 )
사용자 가입경로( 가입경로ID, 사용자ID, 가입경로, 생성일시, 수정일시 )
게시글( 게시글ID, 제목, 코드, 내용, 이미지주소, 말머리, 임시저장여부, 게시판타입, 사용여부, 작성자, 좋아요, 댓글, 상단고정여부, 고정일시, 생성일시, 수정일시 )
댓글 ( 댓글ID, 내용, 게시글ID, 작성자ID, 생성일시, 수정일시 )
좋아요 ( 좋아요ID, 게시글ID, 작성자ID, 생성일시, 수정일시 )
- 확정 ERD
ERD 변경에 따라 많은 수의 코드가 감소되었으며, 유지보수 비용도 줄었습니다.