[Team 16] BE PR입니다.

[street62]

안녕하세요. 16팀의 Heyho, Lee입니다.

저희는 아직 코드로 구현한 사항은 없고요. EC2에 설치한 MySQL을 연결하고, DB와 API 구조에 대해서 논의한 부분들을 정리해 보았습니다. 읽어보시고 피드백 주시면 감사하겠습니다!

MySQL 연결 시 id, password 등의 정보는 application.properties가 아닌, application-aws.properties 파일에 작성해 include하는 식으로 작성하려고 합니다.

질문사항

1. user_action_history는 테이블 명은 user에 관한 것인데, 컬럼에는 user와 관련된 컬럼(id, action_type)과 해당 유저가 액션을 통해 변경한 task와 관련된 컬럼(before_status, after_status, title, created_at)이 섞여 있어서 각 컬럼이 테이블명과 직관적으로 매치되지 않는 것 같습니다. 조금 더 포괄적인 테이블 명이나, 의미가 명확한 컬럼명을 지으려면 어떻게 하면 좋을까요?

DB 구조

회원 관리

회원 API // 회원가입, 로그인, 로그아웃

• 회원 저장 정보는 [id, nickname, password]

회원 활동 기록

회원 활동 기록 API // 특정한 회원의 활동 목록

• 회원 활동 기록 저장 정보는 [id, actionType, beforeStatus, afterStatus, title, createAt] <------------ 추가 논의 필요

• 회원 활동 기록은 TO-DO 글을 등록, 삭제, 내용 변경, 상태 변경을 하는 경우 발생한다.

### actionType : add, remove, update, move

1. add, history에 등록하는 글의 afterStatus, title, action_type, createAt을 기록

• 해야할 일(afterStatus)에 HTML/CSS공부하기(title)를 등록(action_type) 하였습니다.

2. remove, history에 삭제하는 글의 beforeStatus, title, action_type, createAt을 기록

• 해야할 일(beforeStatus)의 HTML/CSS공부하기(title)를 삭제(action_type) 하였습니다.

3. update, <------------ 추가 논의 필요

• ~에 ~를 ~했습니다.(?)

4. move, history에 상태를 변경하는 글의 title, beforeStatus, afterStatus, action_type, createAt을 기록

• HTML/CSS공부하기(title)를 해야할 일(beforeStatus)에서 하고 있는 일(afterStatus)로 이동(action_type) 하였습니다.

DO_LIST 관리

DO_LIST API // 전체 목록 호출, 등록, 삭제, 내용 변경, 상태 변경

• DO_LIST 저장 정보는 [idx, title, content, author, status, createAt]
• 각 API를 호출할 때 마다 사용자의 활동 로그를 DB에 기록하기.

1. content 글자수 제한은 500자 이내, title 글자 수는 아직 미정.
2. 글을 등록, 삭제, 수정, 상태를 변경할 때 매 번 전체 목록 요청을 하지 않고 각 action 결과에 따라 view 단에서 변경 되게끔 처리
3. 조회 요청 시 TO-DO 글 목록을 한번에 json 형식으로 key값에 상태 코드, value값에 각각의 목록을 담은 배열을 보내기.
   ㄴ 배열은 글 작성시간 기준으로 내림차순(최신 글이 앞쪽으로) 정렬해서 보내주기.

아래는 목록 조회 요청 시 전송할 json 데이터의 예시

{
    "status": {
        "todo": [
            {
                "idx" : "1",
                "title": "제목1",
                "content": "해야할 작업..1",
                "author": "apple",
                "createAt": "2011-08-21 14:11:09(형태 미정)"
            },
            {
                "idx" : "2",
                "title": "제목2",
                "content": "해야할 작업..2",
                "author": "grape",
                "createAt": "2011-08-21 14:11:09(형태 미정)"
            }
        ],
        "doing": [
            {
                "idx" : "4",
                "title": "제목1",
                "content": "진행중인 작업..1",
                "author": "banana",
                "createAt": "2011-08-21 14:11:09(형태 미정)"
            }
        ],
        "done": [
            {
                "idx" : "3",
                "title": "제목1",
                "content": "완료한 작업..1",
                "author": "kiwi",
                "createAt": "2011-08-21 14:11:09(형태 미정)"
            },
            {
                "idx" : "5",
                "title": "제목2",
                "content": "완료한 작업..2",
                "author": "pear",
                "createAt": "2011-08-21 14:11:09(형태 미정)"
            }
        ]
    }
}

[wheejuni]

리뷰가 조금 늦어지고 있네요.. 곧 해드릴게요!

[wheejuni]

우선 질문에 대한 답변을 드리자면.... 이게 칼럼명 변경이나 포괄적인 테이블명으로 해결이 가능할까요? 전 그렇게 생각되지 않는데요...
테이블이 하나 더 나와야 하는 것 아닐까요? 어떻게 생각하세요?

[wheejuni]

수고 많으셨습니다. 어째선가 변경분량은 다 모바일 코드군여
일단 제 답변에 대해 충분히 수긍하실때까지 머지는 미뤄둘게요~

[wheejuni]

BE PR인데 모바일측 코드가 섞였군요.

[dongkyu-park]

저희가 팀에서 branch 관리하기로 정했던 방식을 제대로 이해하지 못해서 ios팀의 변경 된 코드만 올라간 것 같습니다. BE팀은 추가 된 코드가 DB 연결 정도밖에 없어서, 코드 반영 없이 질문만 드리고 싶어서 변경 사항이 없다고 생각한 team-16 브랜치를 upstream 저장소의 team-16 브랜치로 PR 요청을 날렸었습니다.

[wheejuni]

오 오랜만에 보네요 SceneDelegate
AppDelegate 도 기대해도 되겠습니까? ㅋㅋ

[wheejuni]

아 여기 있군요 ㅋㅋㅋ

[dongkyu-park]

죄송합니다.. comment를 남기려다가 실수로 PR을 닫아버렸네요😱

[dongkyu-park]

우선 질문에 대한 답변을 드리자면.... 이게 칼럼명 변경이나 포괄적인 테이블명으로 해결이 가능할까요? 전 그렇게 생각되지 않는데요... 테이블이 하나 더 나와야 하는 것 아닐까요? 어떻게 생각하세요?

리뷰 해주신 내용으로, 테이블 구조에 대해 고민을 해봤습니다.

위와 같은 형태로 분리를 시도해 보았다가, 이게 괜찮은 구조인가? 에 대해 Lee와 함께 고민해 보았습니다. task의 데이터가 변경되는 것은 사용자가 행한 action에 의해 데이터가 1:1 매칭으로 생성이 되는데, 회원 활동 이력이라는 범주가 필요한 것인가에 대한 의문이 들었습니다.

실제로 로깅에 필요한 핵심이 되는 데이터는 task의 변경 로그 데이터인데 너무 사용자의 로그를 기록해야 한다는 것에 초점이 맞춰져 있었다는 생각이 들었습니다.

그래서 관점을 바꿔 위와 같이 task의 변경 이력을 남기는 테이블을 만들고, 변경자와 변경의 종류를 넣어서, 사용자의 활동 이력을 조회할 때 사용자를 쿼리 조건으로 걸어 해당 사용자가 task를 변경 시킨 이력을 반환하는 형식으로 가는 것이 어떨까는 결론이 나와 방향을 바꿔 보았습니다.

[wheejuni]

@street62 네 좋습니다. 저도 이런 방향의 설계를 기대한 것이기는 합니다. 좋습니다~