출석체크 현황 엔티티 구현 및 관리 방법 구상

[zjxlomin]

1. MemberAttendanceThisMonth

• 이번 달의 출석체크 현황과 제일 최근의 출석체크 결과를 저장함
• month: 제일 최근 출석일자의 년월 (ex. "2026-01")
• latestDay: 제일 최근 출석일자 (ex. "15")
• combo: 현재 연속 출석일수
• dayList: 이번 달 출석한 날짜들을 쉼표로 구분된 문자열로 저장 (ex. "1,2,3,5,6,11,12,")

2. MemberAttendancePrevMonth

• 이번 달 이전의 출석체크 결과를 저장함
• month: 연월 (ex. "2025-12")
• isFirst: 해당 연월이 유저의 첫 출석인지 여부. true면 프론트에서 이 이전의 결과를 조회하는 것을 방지하기 위한 용도?
• dayList: 해당 연월의 출석체크 결과. ~~ThisMonth와 같이 문자열로 저장

3. 출석체크 결과 저장/수정 로직

위처럼 다섯 가지 케이스로 생각해 보았습니다.

유저의 첫 출석인 경우에만 POST요청으로 진행되고, 이후 출석은 PUT 요청으로 이루어지는 로직입니다.

[sleepyhoon]

편의상 MemberAttendanceThisMonth 테이블은 thisMonth, MemberAttendancePrevMonth 테이블은 prevMonth 테이블로 하겠습니다.

1. thisMonth 테이블에는 이번달 데이터만 들어가도록 하는건가요? 그렇다면 매달 1일 새벽 6시에 스케줄러(아니면 배치서버)를 통해 prevMonth 로 옮기는 작업을 시행하나요? (사실 이번달 첫출석 month, dayList 그대로 지난달 결과로 prevMonth에 저장한다는 것을 이해 못했습니다. 하하)

2. 유저의 첫 출석인 경우에만 POST요청으로 진행한다고 했는데, 프론트엔드에서 첫 출석임을 확인하려면 현재 유저의 출석 상태를 1번 조회해야 하는 것인가요? API를 분리할 것인지 궁금합니다.

3. month, lastDay를 분리한 이유가 궁금합니다. DateTime 필드 1개만 사용하는 것과 차이가 있나요?

4. 이전에 상의한 대로 <userId, date> 유니크 제약조건을 걸면 성능 향상이 될 것 같습니다.

[unikal1]

당월과, 이전 기록으로 나누는건 괜찮은 아이디어 같습니다. 이걸 메인으로 하여 몇가지 추가적인 제안사항을 드립니다.

1. 제가 이해한 바에 따르면 thisMonth 테이블에 당장 "오늘의 출석"을 저장하고, prevMonth 테이블에는 가령 다음 달 1월 쯤에 thisMonth 테이블에서 출석 기록을 가져와 1개월을 하나의 row 로 정리하자는 의견인 것으로 이해했습니다.

2. 해당 월 출석일자 리스트를 문자열로 저장한다고 하였는데 차라리 비트마스킹이 어떨까요? 구분하기 편하게 32비트로 두고 0비트는 1일 , 30비트는 31일, 31 비트는 비워 두는 형식으로 가면 더욱 효율적일 듯 합니다.

3. thisMonth 로 분리하니 콤보나 다른 여타 비정규화 요소들이 오히려 안좋아 보입니다. 제가 연속된 날짜를 기록하자는 것은 결국 테이블에 데이터가 너무 많이 쌓일 까봐 그런 것인데 한달 단위로 하자면 그리 많은 행이 쌓일 것 같지 않습니다. 오히려 현재 방식대로 간다면 추후 새로운 달에 이전 달 기록을 합쳐 prevMonth 하는 과정에서 너무 많은 수고로움이 들듯 하여, (DB 상에서 처리 못하고 application 까지 올려야됨) 차라리 날짜 - 유저 같이 정석만 기록하는 건 어떨까요?

[zjxlomin]

상의한 내용대로 위처럼 진행하도록 하겠습니다.

• 이번달 출석일별로 row 저장
• 1일 06시에 thisMonth 초기화, prevMonth에 월별로 저장