📕 11월 03일 스크럼 기록

어제 한 일

• UI 컴포넌트 사용 여부 결정 → 미사용(styled-components 직접 만들어서 사용)
• 마크다운 뷰어 추가 및 테스트
• styled package 추가
• 문제 조회 페이지 layout 배치 일부 완료
• 임시 헤더 및 navbar 설정
• 메인 글씨체 선정 Noto Sans KR

오늘 할 일

• 마스터 클래스 상태 관리 총정리 듣기
• 문제 리스트 페이지(홈페이지) layout 배치
  • 문제 컴포넌트
• header, navbar 정돈
• 문제 출제 페이지 layout도 할 수 있으면 배치 해보자.
• 배포? Nginx? https?

결정 사항

• Database 결정

  • ORM : TypeORM(Typescript를 사용하고 Spring의 JPA ORM과 비슷하다.)

  • NoSQL vs RDBMS

    NoSQL vs. SQL - How NoSQL is Better for Big Data Applications? - Whizlabs Blog

    • NoSQL(MongoDB)
      • 코드를 저장할 때 타입을 깊게 고민할 필요가 없다.
      • RDBMS에 비해 엔티티 형식이 자유롭다.
      • NoSQL은 Column-based store기 때문에 대용량 데이터의 통계(Aggregation)에 유리하다.
      • 아주 작은 데이터 손실율이 존재한다.(= 중요한 데이터를 저장하기에는 적합하지 않다.)
    • RDBMS(Mysql)
      • 코드를 저장하기에 TEXT 타입은 너무 작지 않나?
        • TINYTEXT, TEXT, MEDIUM TEXT, LONGTEXT를 지원한다.
        • BUT, TEXT 타입은 길이가 고정이며, MEDIUMTEXT(16MB), LONGTEXT(4GB)는 용량을 너무 많이 차지한다.
      • 코드나 문제를 파일로 저장하여 Object Storage에 업로드하고, DB에는 경로를 저장한다.
        • 파일 I/O는 시간이 오래 걸리는 작업인데 프로젝트에 적합할까?
      • 중간에 엔티티의 형식이 바뀌면 테이블에 수정사항을 반영하기 어렵다.

저장 해야할 데이터 목록

• 문제 - id, 문제(a), 테스트 케이스, 출제자, 코드(a)
• 계정 - id, 깃허브 아이디, accessToken, 닉네임, 프로필(https://github.com/깃허브아이디.png), 푼 문제 횟수, 맞은 갯수, 틀린 갯수, 성공률, 제출 횟수
• 문제 풀이 로그(a) - id, 문제번호, 계정(깃허브 아이디), 통과 여부(테스트 케이스 통과 갯수), 제출 코드(a)
• 랭킹 - 순위, 계정 아이디, 푼 문제 횟수