[회의] BackEnd 4차 회의

개요

일시	2024.07.21 (일)
주제	역할 분담 및 ERD 작성

3차 회의는 2차 회의 숙제 정리본 & 기획 Q&A라서 생략

Problems

1. 역할 보여주기

• (8/10)처럼 (현재 지원한 인원/모집 인원)을 보여줘야 한다

• 방법
  1. [Get] : 역할을 볼 때마다 지원 요청 개인 & 하청에서 role_id가 있는 record를 count 한다
     • transactional read only
  2. [Post] : 지원 요청 | 취소 api가 들어올 때마다 count를 수정한다
     • 지원수 증가 → count++
     • 지원수 감소 → count--
     • 동시에 신청 시 동기화 문제 발생

2. 타투 저장 방식

(얘는 조금 말이 많았다. 어떤 방식이 적합한지 모르겠어서..)

조건 : 한 회원이 여러 개의 문신을 할 수 있고, 문신한 위치 정보까지 기록되어야 한다.

기존에는 단지 문신 여부만 Boolean으로 결정하고 있었고, 문신 여부뿐 아니라 문신의 위치까지 저장해야 하기 때문에, List로 받거나 다른 테이블로 만드는 등 다른 방식이 필요할 것이라고 생각했다.

(1) Tattoo 테이블을 따로 만들고, MemberTattoo 테이블에 외래키로 참조하자

• Tattoo 테이블을 따로 만든다.
• Tattoo 테이블의 기본키(tattoo_id)를 MemberTattoo에서 일대다로 받는다.
• 장점
  • 불필요한 데이터나 Null값 없이 필요한 데이터만 저장된다.
  • 새로운 타투 위치가 생길 경우 Tattoo 테이블에 추가 및 수정만 해주면 되기 때문에 관리가 편하다.
• 단점
  • 타투는 신체 부위에 하는 것이기 때문에 수정 가능성이 높지 않고, 그래서 2번째 장점(관리 원활)을 잘 살리기가 어려울 것이다.
• 연산 - 단순한 테이블보다 연산이 복잡함
  • 저장
    
    1. 얼굴에 타투를 했다는 post request
    2. name : 얼굴을 findByName으로 Tattoo 탐색 & user_id를 통해 findById로 User 탐색
    3. MemberTattoo에 Tattoo와 User를 매핑
    4. MemberTattoo save
  • 탐색
    1. 얼굴에 타투한 user 찾기
    2. findByName(얼굴)으로 Tattoo 탐색 & tattoo_id가 1인 MemberTattoo만 탐색
    3. MemberTattoo에서 getUser한 다음 얘를 List로 만듦
    4. return UserList
• 기타 발생 → Tattoo에 새로운 레코드 추가하고 외래키 참고

(2) Tattoo 테이블을 따로 만들고, 신체 부위를 전부 attribute로 만든 다음 Boolean으로 다룬다.

• Tattoo 테이블을 따로 만든다.
• Tattoo 테이블이 User 테이블과 일대일 매핑
• 장점
  • 테이블 개수가 하나로 합쳐지면서 join 연산이 불필요해 진다.
• 단점
  • False는 필요 없는 데이터기 때문에 저장 공간 낭비가 심하다.
• 연산 - (탐색 1번)
  • 저장 
    1. 얼굴에 타투를 했다는 post request
    2. user_id를 통해 findById로 User탐색
    3. Tattoo 생성자를 만들 때 얼굴 field에 True 저장
    4. Tattoo save
  • 탐색
    1. 얼굴에 타투한 user 찾기
    2. Tattoo 테이블에서 findByFace(True)인 것만 탐색해서 User 가져오기
    3. return UserList
• 기타 발생 → 기타 attribute를 만들고, 그 안에 string으로 입력한 위치 저장

결론

• 타투는 신체기 때문에 우후죽순 늘어나지 않음, 그 외의 것도 string으로 받아서 저장 → 스키마 변경 가능성 낮음
• 일반적으로 MemberTattoo 레코드 수보다 Tattoo 레코드 수가 적을 것
  • ex) user A - 얼굴, 가슴, 팔, 다리 타투
  • MemberTattoo → record 4개
  • Tattoo → record 1개
• 우선 (2) 방식대로 하기로 하고, 추후 문제 발생 또는 성능 비교 후 다시 결정

과제

• jwt 로그인에서 redis + refresh token + black list 사용 이유 조사
• 알람 기능 DB 조사
• table 수 vs record 수