지난 포스팅에서 다뤘듯이, 본격적인 프로젝트 개발에 앞서 팀원들과 함께 Database Table을 설계했고 멘토님께 이에 대한 피드백을 받았다.
부족한 건 알고 있었지만 고쳐야 할 부분이 많았다 헤헤😅
그렇지만,
오히려 좋아^^!!!!!!!!
배울 게 많다는 뜻이니까!
피드백을 들으면서 역시 실무에서 직접 개발을 많이 해 본 분들은 다르구나 느꼈고, 자세하고 친절한 조언들로 의지가 더욱 뿜뿜해졌다!
피드백 받은 내용과 최종적으로 만들어진 테이블에 대해 정리해보겠다.
🏷 피드백 내용
1. Tag 테이블
<피드백 내용>
- Post 테이블과 Tag 테이블이 다대다 매핑인 만큼, 가운데에 매핑 테이블을 따로 생성하는 것을 추천
- 생성, 수성, 삭제가 조금 번거로워지더라도 조회를 가장 간단하게 만드는 것이 좋음
- "사용자는 생성, 삭제가 오래 걸리는 건 참아도 조회가 오래 걸리는 건 못 참는다!"
- 조회 시
JOIN이나WHERE절을 최대한 간단하게 만들어야 함
<변경 후>
- Post 테이블과 Tag 테이블 사이에
태그-게시글 매핑테이블을 따로 생성해 다대다 매핑을 만들어주었다. - tagPostMapping 테이블에는 간단하게 기본
id,tagId,postId가 존재한다. - Tag 테이블의
tagCountweekCount필드는 Explore 테이블에서 설명하겠다.
2. Recomment 테이블
<피드백 내용>
- 대댓글 UI가 존재하는 지 확인할 것
<변경 후>
- 대댓글 UI가 존재하는 줄 알았는데 없어서 과감히 테이블을 삭제했다^^!
3. Feed 화면
<피드백 내용>
- 프로젝트 규모가 크지 않다면 테이블끼리 조인하여 조회해도 괜찮지만, 규모가 크다면 조회 성능이 안 좋아질 가능성이 큼
- 메인 화면은 시간이 짧을수록 좋고, 그래서 요즘 현업에서는 메인 화면에 보여줄 테이블을 따로 생성하여 관리하기도 한다.
- 테이블에 넣어주는 기준(메인 화면에 게시글을 보여주는 기준)은 팀원들과 논의하여 결정
<변경 후>
- 컬럼으로는 기본
id,userId,postId,createdAt을 가진다. - 만약 a 를 b, c 가 팔로우하고 있는 상태에서 a 가 1번 글을 쓰면, Feed 테이블에
(b, 1, 시간),(c, 1, 시간)과 같은 형태로 데이터가 추가된다.
(이 때 시간은 피드 테이블 기준으로 추가) - 그래서 나중에 b 가 메인 화면을 조회하면 Feed 테이블에서 b 를 기준으로 조회하여 게시글 보여줄 수 있게 된다!
4. 게시글, 사용자 삭제
<피드백 내용>
- 보통 status를 두고 관리하기도 하는데 이 방법은 조회 시
where절에 조건이 추가되기 때문에 추천하지 않음 - 현업에서는 삭제 테이블을 따로 두고 게시글을 삭제하는 경우, 해당 게시글 정보를 삭제 테이블에 복제하고, 게시글 테이블에서는 삭제하는 방식으로 함
- 삭제 테이블에서 언제 삭제할지는 정책에 따라 결정
<변경 후>
- 삭제한 게시글을 관리하는 deletePost 테이블을 생성했다.
- 만약 사용자가 탈퇴하더라도 사용자의 글은 보여주고 싶다면, User 테이블에
userId만 남기고 나머지 정보를는 모두 삭제한다.
이렇게 하면 탈퇴한 사용자의 게시글을 조회는 가능하게 되고, 사용자 정보를 보여주는 부분은 (알수없음) 과 같이 처리를 하면 된다. - 사용자 비활성화, 블랙 유저 등 관리도 사용자 상태 테이블을 따로 생성하여 관리하는 것을 추천한다!
5. 문의글
<피드백 내용>
- 문의글은 멘토님도 따로 염두에 두고 계시지는 않았지만 구현해보는 것을 추천함
- 테이블로 관리하고 만약 이를 이메일로 바로 전송하게 하고 싶으면 SMTP 서버를 사용해 시도해보는 것도 좋음
<변경 후>
- 팀원들과 상의한 결과 Contact 테이블은 생성한 대로 두고, 모든 기능을 구현한 뒤 시간적 여유가 있으면 빠르게 개발해보기로 결정했다.
6. 검색 조건
<피드백 내용>
- 검색 기능 구현 시 검색 기준 고민해보기
ex) 사용자 검색, 게시글 검색, 태그 검색 등 - 그리고 검색 후 보여주는 방식도 고민해보기
ex) 검색 결과의 노출 순서, 태그/사용자/게시글 검색 결과를 섹션을 나눠서 따로 보여줄지 등
<변경 후>
userId를 기준으로 조회, 검색어를 통한 조회, 태그 조회
위 3가지의 기준으로 조회를 하기로 결정했다.- 변동될 가능성도 있지만, 검색 기능을 개발하는 시기에 더 자세히 이야기해보기로 했다.
7. Trending, Explore 조회 기준
<피드백 내용>
- Trending 테이블을 따로 만드는 것을 추천 (조회할 때 성능 고려)
- Trending 과 Explore 테이블을 어떤 기준으로 보여줄건지 정해야 함
<변경 후>
- Trending 테이블을 생성하였고 기본
id,postId,createdAt을 컬럼으로 가진다. - Trending 은 좋아요와 리그램 개수를 기준으로 보여준다.
- Explore 테이블을 생성하였고 기본
id,tagId,createdAt을 컬럼으로 가진다. - 가장 언급이 많이 된 태그를 총 누적해서 보여주는 방식과 주마다 카운팅해서 보여주는 방식 2가지 구현을 위해 Tag 테이블에
tagCount,weekCount컬럼을 추가했다. - Batch 프로그램을 통해 통계를 내어 이를 기준으로 정렬하여 보여주기도 하는데 이에 대한 기준은 추후에 자세히 논의해보기로 했다.
🏷 최종 Database Table
깔-끔
다음 포스팅부터는 내가 맡게 된 Post 부분 개발을 시작할 예정이다!
기본적인 CRUD 기능은 지난 블로그 프로젝트 때 경험해보았지만,
이미지 업로드나 태그를 다는 건 처음이라 기대도 되고 살짝 걱정도 된다😂
그래도 최선을 다 해 화이팅~~~🔥🔥🔥🔥
Backend Developer
👍👍