[DOCS] 프로젝트 아이디어

[shininghyunho]

핵심 기능

나와 선수들 비교

• 내가 내 체급에서 얼마정도 되는지(상위 10등 선수의 80%면 엘리트 60%면 고수)
• 내 3대 비율이 평균적인지
• 내 체급(class)과 각 종목 무게(SBD)를 입력하면 정보 제공.
  • 내 3대 비율과 선수들(1등과 평균)의 비율 비교. (내 3대 비율이 일반적인지. 뭐를 더 보충해야할지 찾기 위함.)
• 체급, 무게 입력시 내가 상위 몇 퍼센트인지.
  • 선수들 평균은 잘 안바뀌므로 저장해놔야함.
  • 잘 안바뀌는 정보를 Table로 저장하는건 아닌거같고 어떻게할지 찾아봐야함.
  • 통계정보는 주기적으로 변경해줌(주기적으로 갱신)
• 결국 검색이므로 사용자들의 통계치도 알수있음
  • 이를 통해 다시 새로운 인사이트(검색한 사람들의 평균, 근데 1톤 같이 아무렇게 입력할 가능성이 농후함. 그래서 평균은 의미가 없을듯.)

선수들 정보 제공

• 선수들의 대회 기록 제공.
• 선수들의 기록 변화량.
• youtube 검색

정보 검색

• 최근에 어떤 선수가 핫한지. (체급별, 점수별)

점수 기준

• 구체적인 계산법은 찾으면 됨

  val dots: Double? = null,
  val wilks: Double? = null,
  val glossbrenner: Double? = null,
  val goodlift: Double? = null,

기능상 고려해야할 점

• 레코드 갯수가 약 1만개 정도라 성능을 고려해야함.
• 검색 기능을 고려한 indexing, 테이블 설계

[shininghyunho]

이후 수정해야할것

• Table 마다 fetch 전략. eager or lazy
• 삭제시 cascade 여부

[shininghyunho]

테이블 성능 고려

• 결국 체급에서 비교하는게 의미있으므로 인덱싱은 (몸무게,total) 로

[shininghyunho]

데이터 처리를 위한 코드

• csv 파일을 읽어와서 DB 에 저장하는 서버 따로
• 이는 주기적으로 읽어오고 실행되어야함.

[shininghyunho]

엔티티 관계 다이어그램

AthleteGameRecord

• AthleteGameRecord 는 Athlete 와 Game 에 1:N, 1:N 관계를 해소해줌.
• 해당 테이블은 컬럼이 많지만 동시에 조회되므로 하나의 테이블에서 사용.

[shininghyunho]

진행순서

1. 핵심 기능인 검색 구현 + 테스트 코드
2. DB 서버 구현 (Job 기능 제외)
3. 검색 기능 통합 테스트하며 수정
4. 프론트로 확인