[회의] BackEnd 1차 회의

개요

일시	2024.07.15 (월)
주제	ERD 그리기

ERD 작성을 위해 한 자리에 모여서 열심히 회의를 진행했다.( ᐛ )و

프로젝트 주제는 요약하면, 보조 출연자와 업체 간의 교류를 더 쉽게 해주기 위한 앱+웹이다.

아직 기획이 완전히 끝난 게 아니라 그런지 시나리오부터 생각하면서 들어가서.. 시간이 꽤 걸리지 않을까..(수정 사항도 꽤 많을 것 같다)

---

Problems

ERD 설계는 백엔드 개발의 토대가 되서 중요하게 봐야하는 것도 있고, 정답이 완벽히 정해진 게 아니라 그런지 항상 할 때마다 고민이 많은 것 같다.

1. [기술적 고민] 개인 테이블 설계

개인 테이블을 설계할 때 회원의 로그인&비밀번호 정보나 개인의 정보(나이, 이름, 별명 등)을 다른 테이블로 나눠서 저장하는 경우가 종종 있다.

우리 팀은 로그인과 비밀정보가 접근하는데 큰 정보가 아니고, join 연산을 줄이는 방향이 더 좋을 것 같아 하나로 합치기로 했다.

2. [기술적 고민] 공고글 테이블 설계

공고글에 올라가는 일정과 관련해서 문제점이 생겼다.

드라마를 하루만 촬영하는 경우가 아니라 여러 일자 동안 촬여하는 경우에는 어떻게 데이터를 저장할지 고민이었고 꽤 의견이 분분했다.

1. 첫 날짜와 마지막 날짜만 받아서 저장한 다음에 보여주자
   • 드라마가 항상 연속적으로 찍는 게 아니라 이산적으로 분포될 수도 있다 ⇒ List에 저장해주자

2. List로 저장해서 각 날짜를 list에 넣어주자
   
   • 한 보조 출연자가 12, 13, 14일에 시간이 됨
   • A 드라마를 12, 13일 신청하고 16일은 신청하지 않음
   • 14일에는 시간이 되기 때문에 C 드라마를 신청하고 싶음
   • 12, 13일에는 이미 다른 드라마를 신청했기 때문에 검색할 때 자동으로 필터링을 해줘야 함
   • 리스트를 사용할 경우 모든 공지글의 일정 list 내부로 들어가서 비교하고, 되는 시간만 따로 필터링해서 보여줘야 함.
   • 날짜마다 모집 인원과 시간, 급여, 역할 등이 다르면 이 부분도 따로 저장하기가 어려움 ⇒ 개별 테이블을 생성하자
3. 개별 테이블 생성
   • 이렇게 되면 드라마 A에 12, 13일을 신청하더라도 드라마 C의 14일을 손쉽게 확인할 수 있음
   • 드라마 이름과 집합 장소가 중복되는 경우가 너무 많이 생김 ⇒ 일정 테이블을 분리해서 OneToMany로 연관 관계를 주자
4. 공고글, 일정, 역할 테이블 의존 관계를 줘서 테이블을 전부 분리
   • 추후 역할을 통해 일정, 공고글, 하청 id 등을 검색하려면 양방향 매핑 필요
   • 이렇게 테이블을 여러 개로 나누게 되면 한 번에 데이터를 받아서 넣을 수 있는지 확인해 봐야한다
     • 공고글이 생성되서 DB에 반영되기 전까지는 일정을 생성할 때 공고 id를 참조할 수 없기 때문
     • OneToMany를 사용해서 모든 key를 DB에 위임

3. [기술적 고민] 지원 요청 ERD 설계

보통 업체에서 공고를 올리면 보조 출연자가 공고를 보고 지원을 해야하지만, 업체에서 보조 출연자에게 출연을 요청할 수도 있다고 한다.

이 경우에 회사 → 개인, 개인 → 회사 테이블을 아예 분리할지 아니면, attribute를 추가할지 고민

생각해본 각자의 장단점

	테이블 분리	attribute 추가
장점	- 구분을 위한 추가 로직 불필요 - 하나의 테이블에서 정보를 읽기만 하면 됨	하나의 테이블만 존재
단점	테이블이 2개 생성 (개인 → 회사 지원 / 회사 → 개인 지원)	- [회사 → 0 / 개인 → 1] 일 경우, 중복 데이터가 좀 많을 것 같음 - 회사 → 개인 지원을 보기 위해 개인 → 회사 데이터도 전부 비교해서 가져와야 함

중복 데이터를 줄이는 방향으로 가자고 결론이 나서 테이블을 아예 분리하기로 했다.

---

과제

1. 사용할 DBMS 조사 및 DB 장단점 정리하기
2. WebSocket 학습하기