humansof42seoul / Humansof42-v2

0 stars 1 forks source link

[Feat] 메뉴 구조, 페이지 리스트, DB 설계, UI 설계 #9

Open jwon42 opened 3 years ago

jwon42 commented 3 years ago
jwon42 commented 3 years ago

요구사항

Entity, Attribute 추출

Entity Attribute
회원 회원아이디, 닉네임, 비밀번호, 이메일주소, 프로필이미지, 등급
게시판 제목, 내용, 작성자, 좋아요수, 등록일, 인터뷰이, 인터뷰어, 포토그래퍼
댓글 게시물 번호, 내용, 작성자, 등록일
좋아요 게시물 번호, 회원 아이디
스크랩 게시물 번호, 회원 아이디
파일 게시물 번호, 파일위치, 파일타입(이미지여부), 등록일

DB diagram

https://dbdiagram.io/d/615d59fd825b5b0146236bcc

스크린샷 2021-10-08 오후 7 09 23
jwon42 commented 3 years ago

@jongfeel

질문1 인터뷰 게시판과 랜덤 게시판이 존재하는데 Post Table로 통합 관리하려고 합니다. 첫번째 이유는 성격이 동일한 범주안에 들어간다고 생각해서 이고, 두번째는 Like, Scrap, File, Comment Table에서 사용되는 board_idPost의 기본키로 매핑하면 중복을 신경쓰지 않아도 될 것 같아서 입니다. 인터뷰 게시판에 게시물 작성 시 interviewees, interviewers, photographers 필드에 값이 들어가야하고, 랜덤 게시판에 게시물 작성 시 위 3개의 필드를 제외하고 나머지 not null 필드가 채워집니다. 이렇게 작업하는게 맞는 방향인지, 문제가 있다면 개선 방법 또는 학습이 필요한 부분이 무엇인지 궁금합니다.

질문2 Post Tablelike_count를 만들었습니다. 좋아요를 하거나 좋아요 취소를 했을 때, 해당 필드 값을 업데이트(+1/-1) 할 생각입니다. Like Table이 존재하기 때문에 게시물 로딩 시 바로 계산해서 보여줄 수 있지만, 게시물이 누적될 경우 속도가 느려질 것 같습니다. 이것 또한 이렇게 작업하는게 맞는 방향인지, 문제가 있다면 개선 방법 또는 학습이 필요한 부분이 무엇인지 궁금합니다.

jongfeel commented 3 years ago

조금 쉽게 가기 위해서 table을 따로 쓰는 게 좋을 것 같습니다. 나중에 합치는게 좋을 것 같다는 증거가 확실히 드러나면 그때 해봐도 좋을 것 같네요.

두번째 속도 문제는 게시판 글이 엄청나게 많을 때나 신경 쓸 법한 문제입니다. 그리고 로딩 속도에 문제를 줄 정도라면 적절한 게시글을 갯수만큼 가져와서 처리하는 방법이 있습니다.

joho3116 commented 3 years ago

수정사항

interview 테이블을 따로 작성, post의 type이 인터뷰일 경우, post의 index를 참조한 board_id로 접근해 해당 인터뷰 대상자, 인터뷰 작성자, 포토그래퍼 밸류를 가져옴

스크린샷 2021-10-23 오후 8 30 48
jongfeel commented 3 years ago

Interviewee Interviewer photographer

각각의 table로 할 줄 알았는데 아니군요.

joho3116 commented 3 years ago

생각해보니 인터뷰 게시물 양이 얼마 되지 않을거같아서 저렇게 구현해도 괜찮을 거 같아서 해봤습니다!

jongfeel commented 3 years ago

하면서 나중에 잘못됐다 싶으면 고쳐보면 됩니다. 만약 그런 일이 일어나면 좋은 학습의 기회로 삼아보시면 좋을 것 같아요.