Discussed in #3
Originally posted by on-Sync January 20, 2022
@parkhr @daehwan2 @yunjin-kim
이번 주말에 진행할 항목 중 데이터 설계가 있습니다.
이는 DDD 관점에서 설계를 생각할 수도 있습니다.
하지만 다른 관점으로 개선사항에 따른 데이터 처리형태도 의견을 나누고 싶습니다.
잠깐 생각해도 다른 방법이 존재하길래, 좋은 생각있으면 Reply mention 부탁드립니다.
문제점
기존 원드컵은 등록 갯수의 차이가 너무 큽니다. ( 2의 진수 )
이 경우, 16개부터 32, 64, 128 등 고객의 노력이 많이 요구됩니다.
해결방안
- 등록 자료의 Max 갯수만 설정합니다. ( 서버 용량 고려 )
- 백엔드는 다음 알고리즘을 적용합니다.
- 각 단계 시작 전에 다음 단계의 종료 조건을 현재 대상이 반이 되는 횟수로 구합니다.
- 각 대상의 순서를 랜덤적으로 정렬합니다.
- 매칭대상(2개)별로 짝을 이루고 마지막 대상을 부전승(홀수)로 분리합니다.
- 부전승이 랜덤적으로 제공될 수 있도록 2번 항목을 다시 한번 수행합니다.
- 해당 리스트를 프론트에 반환합니다.
- B. 프론트는 다음과 같이 화면을 처리합니다.
- 요청 후 받은 리스트 정보를 토대로 화면을 구성합니다.
- 이때,
짝/홀 을 고려하여 리스트의 정보로 사진 또는 영상 등 매칭정보를 요청합니다.
- 반환된 매칭정보를 토대로
짝/홀 에 대한 조정화면을 제공합니다.
Discussed in #3
Originally posted by on-Sync January 20, 2022
@parkhr @daehwan2 @yunjin-kim
문제점
해결방안