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

[jwon42]

• 메뉴 구조 ([Feat] 페이지 구조 (2021/09/15 회의) #4 참고)
  

• 페이지 리스트 ([Feat] 페이지 구조 (2021/09/15 회의) #4 참고)
  
  마이페이지 등의 상세 페이지가 누락되었네요. 업데이트하겠습니다. (2021-10-08)

• DB 설계 - 관계형db에 대해서 공부가 좀 필요하네요. 수정중입니다.
  https://dbdiagram.io/d/615d59fd825b5b0146236bcc

  • 회원 테이블
    • 42auth 인증 가입 후 이메일 입력을 받아야 함 - 비밀번호 찾기 용도, 가입 시 이메일 인증 필요
  • 관계 되는 요소들간의 연결에 어떤 방법(foreign key, unique key)이 적당한지 작성자, 좋아요수 등
  • 데이터베이스의 세계도 엄청 넓구나 라는걸 느낌..

• UI 설계 -> [Feat Request] 플로우 차트, UI 설계 #10 이슈로 토스

  • flow chart 및 ui 설계(디자인x) 필요

[jwon42]

요구사항

• Humans of 42에 가입하려면 42인트라 인증 후 회원id, 닉네임, 이메일(비밀번호 찾기 기능을 위해)을 입력해야 한다.
• 42인트라 인증이 불가(인트라 접근 기간 종료 등)한 회원의 경우 일반회원 가입 후 승인절차(재단을 통한 확인)가 필요하다.
• 모든 회원은 마이페이지에서 내 글, 내 댓글, 스크랩 한 글, 좋아요 한 글을 확인할 수 있고, 정보 수정과 탈퇴 기능을 제공한다.
• 회원 등급을 구분한다. 인터뷰 업로드 권한을 제한하고자 하는 용도이고, 그 외 일반회원, 승인대기회원으로 구분한다. 추후 확장(기업회원 등)이 필요하다.
• 인터뷰 게시판과 랜덤게시판이 있고, 게시판이라는 하나의 틀 안에 모든 포스팅은 카테고리(타입)를 이용하여 식별한다.
• 게시판에 필요한 정보는 제목, 내용, 작성자, 조회수, 좋아요수, 등록일(수정일)이다.
• 인터뷰게시판에 별도로 필요한 것은 인터뷰이, 인터뷰어, 포토그래퍼 정보이다.
• 게시판에는 좋아요 기능과 스크랩 기능이 있고, 두 기능은 같은 포스팅에 한해서 중복해서 적용될 수 없고, 취소가 가능하다.
• 게시판에는 댓글 기능이 있다. 대댓글은 지원하지 않는다.
• 게시판에는 파일(이미지) 첨부 기능이 있다. 다중 파일 첨부가 가능하다.

Entity, Attribute 추출

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

DB diagram

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

[jwon42]

@jongfeel

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

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

[jongfeel]

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

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

[joho3116]

수정사항

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

[jongfeel]

Interviewee
Interviewer
photographer

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

[joho3116]

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

[jongfeel]

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