오늘의 이슈 이슈를 설명하기 전 주요 정보 Match 도메인은 매치를 등록하는 도메인이다. Apply도메인은 Post되어있는 Match에 신청할 수 있는 도메인이다. Apply는 Team_Apply, League_Apply, Match_Apply가 있으며 각각 Team_List, League_List, Match_List 와 일대다의 연관관계를 맺고 있다. Match_List 도메인은 Match에 참여하는 A팀과 B팀의 정보를 담는 도메인이다. Match는 일반 매치와 리그 매치를 post한다. 일반 매치의 flow는 다음과 같다. Match를 만든 A팀은 Home 팀이 된다. Match를 Post과 동시에 Match_List가 Post된다. Match_List에 A팀의 정보가 삽입된다. B팀은 Appl..
오늘 다룰 내용 Match 테이블과 Team의 다대다 연관관계 필요성에 관련한 문제 문제 발생의 이유 다대다 연관관계를 형성하는 경우 관계형 데이터베이스에서 정규화를 할 수 없다는 문제점이 있다. 이는 숨겨진 테이블이 형성될 수 있다는 이슈를 야기할 가능성이 있으므로 반드시 필요한 경우가 아니라면 지양해야 한다. 문제 해결 방법 새로운 테이블을 생성하여 테이블 간에 관계를 한 단계 더 만들어 주는 것이 방법이 될 수 있다. 다시 말해, A와 B라는 테이블을 다대다로 연관지어야 할 상황이 발생한다면 C라는 테이블을 새롭게 생성하고 "A -> C", "B -> C"로 일대다 연관관계를 맺어주는 것이 해결방법이 될 수 있다. # 유저와 게시글, 댓글의 상관 관계를 고민해본다면 쉽게 이해할 수 있다. 로직 설명..
ERD 설계 모두의 게시판은 커뮤니티 게시판으로 유저(users)와 게시글(contents), 댓글(comments)을 메인 테이블로 구성하였다. 따라서, 초기 테이블 설계는 유저와 게시글, 댓글을 메인으로 유저에는 유저 이미지, 유저 역할이 하위로 게시글에는 게시글 이미지, 게시글 좋아요, 스크랩이 하위로 댓글에는 댓글 좋아요, 대댓글, 대댓글 좋아요가 하위로 테이블을 구성하였다. 이러한 테이블 설계는 초기 백엔드 멤버가 3인으로 구성되었기 때문에 테이블을 3:4:4 단위로 고른 역할 분배를 할 수 있다는 장점이 있었기 때문에 다음과 같이 테이블을 설계하였다. 따라서 각 구성원들은 유저, 게시글, 댓글 단위로 역할을 분담하여 테이블을 설계 및 구현하였다. 테이블 설명 users - 유저 정보를 저장하는..
프로젝트 소개 저희 Every-Board팀은 개발자에게 있어서 가장 중요하면서도 기본기를 잘 보여줄 수 있는 프로젝트를 목표하여 "기본적이지만 잘 만든 게시판"을 주제로 "Every-Board(모두의 게시판: 프로젝트 네임)"을 제작하게 되었습니다. 커뮤니티형 게시판 게시판은 다양한 방식으로 구현할 수 있는데요, 초기에 저희 팀에서 고민한 UI는 다음과 같습니다. 카카오 TALK과 같은 스타일의 UI 장점 - 모바일 친화적인 UI 단점 - PC환경에서 적합한 UI가 아님 플랫폼 스타일의 UI 장점 - 테마가 정해져 있어 기획의도가 명확함 단점 - 행사 테마를 관리자가 주기적으로 업로드 해야하며, 관리자가 부분적으로 개입해야하는 요소가 있음 (애자일에 불리함) 커뮤니티 스타일의 UI 장점 - 구조가 간단함..
