Open jwon42 opened 3 years ago
Entity | Attribute |
---|---|
회원 | 회원아이디, 닉네임, 비밀번호, 이메일주소, 프로필이미지, 등급 |
게시판 | 제목, 내용, 작성자, 좋아요수, 등록일, 인터뷰이, 인터뷰어, 포토그래퍼 |
댓글 | 게시물 번호, 내용, 작성자, 등록일 |
좋아요 | 게시물 번호, 회원 아이디 |
스크랩 | 게시물 번호, 회원 아이디 |
파일 | 게시물 번호, 파일위치, 파일타입(이미지여부), 등록일 |
@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
이 존재하기 때문에 게시물 로딩 시 바로 계산해서 보여줄 수 있지만, 게시물이 누적될 경우 속도가 느려질 것 같습니다.
이것 또한 이렇게 작업하는게 맞는 방향인지, 문제가 있다면 개선 방법 또는 학습이 필요한 부분이 무엇인지 궁금합니다.
조금 쉽게 가기 위해서 table을 따로 쓰는 게 좋을 것 같습니다. 나중에 합치는게 좋을 것 같다는 증거가 확실히 드러나면 그때 해봐도 좋을 것 같네요.
두번째 속도 문제는 게시판 글이 엄청나게 많을 때나 신경 쓸 법한 문제입니다. 그리고 로딩 속도에 문제를 줄 정도라면 적절한 게시글을 갯수만큼 가져와서 처리하는 방법이 있습니다.
interview 테이블을 따로 작성, post의 type이 인터뷰일 경우, post의 index를 참조한 board_id로 접근해 해당 인터뷰 대상자, 인터뷰 작성자, 포토그래퍼 밸류를 가져옴
Interviewee Interviewer photographer
각각의 table로 할 줄 알았는데 아니군요.
생각해보니 인터뷰 게시물 양이 얼마 되지 않을거같아서 저렇게 구현해도 괜찮을 거 같아서 해봤습니다!
하면서 나중에 잘못됐다 싶으면 고쳐보면 됩니다. 만약 그런 일이 일어나면 좋은 학습의 기회로 삼아보시면 좋을 것 같아요.
[x] 메뉴 구조 (#4 참고)
[x] 페이지 리스트 (#4 참고)
마이페이지 등의 상세 페이지가 누락되었네요. 업데이트하겠습니다. (2021-10-08)
[ ] DB 설계 - 관계형db에 대해서 공부가 좀 필요하네요. 수정중입니다. https://dbdiagram.io/d/615d59fd825b5b0146236bcc
[x] UI 설계 -> #10 이슈로 토스