.case(등록/해제/재등록 날짜 기록 프로세스)

고민

• 게시물에 대한 등록과 해제 및 재등록이 있는 경우 처리날짜를 어떻게 기록하면 좋을까.

결론

• 기획에 따라 방향을 정한다. 사실 이런 변경 테이블 데이터 변경이 일어난다면 로그 플랫폼을 분리해서 관리하는 3번이 가장 이상적으로 생각한다. 처음 구현이 복잡한데 이후로 처리할 잡다구리한 일들이 적어진다.

접근방법

1. 하나의 테이블에서 관리

• 등록일/ 해제일/ 필드를 만든다.
• 등록하면 등록일에, 해제하면 해제일에 데이터를 저장한다.
• 재등록하면 기존 목록에서 등록일만 있는(해제일이 없고) 있는 목록이 있는지 확인한다. 없다면 등록을 허용한다.
• 이렇게 되면 하나의 주제에 대해서 여러개의 목록이 생길 수 있다.
  ex) 티스토리와 연동/ 등록일:2021-01-01/ 해제일:2021-01-10

  티스토리와 연동/ 등록일:2021-01-14/ 해제일:x            << 재등록

2. 로그 테이블을 따로 관리, 하나의 테이블에서는 상태만 관리

• 상태(등록/해제/재등록)을 필요한 테이블에서 관리한다.
  • 재등록으로 상태를 표시할지, 등록으로만 표시할지는 기획에 따른다.
  • 재등록시 표현하고 싶다면 로그 전용 테이블에서 조회해보고 있으면 재등록, 없으면 등록으로 표시하면 된다.
• 로그 전용 테이블을 만들어서 따로 쌓는다.
  • aop와 같은 형태로 annotation을 이용해 관리하면 SRP에 입각하여 개발할 수 있다.
    ex) 테이블1 - 티스토리와 연동/ 상태:재등록
    테이블2 - 티스토리와 연동/ 등록/ 2021-01-01
    테이블2 - 티스토리와 연동/ 해제/ 2021-01-10
    테이블2 - 티스토리와 연동/ 등록/ 2021-01-14

3. 로그를 따른 플랫폼으로 사용, 상태테이블만 관리

• 이전상태에 따라 영향받아서 처리도 가능하다.
• 이전 데이터가 없으면 -> 등록, 이전 데이터가 등록이면 -> 해제, 이전 데이터가 해제면 -> 재등록
• 물론 유효성검사를 잘 해줘야한다. 테이블에 데이터를 조회해서 상태에 따라 동일한 상태로의 저장을 방어
• 로그는 es와 같이 우리가 쉽게 경향성을 파악할 수 있고 통계도 뽑아볼 수 있는 프레임워크가 좋다.
  • aop와 같은 형태로 annotation을 이용해 관리하면 SRP에 입각하여 개발할 수 있다.
    ex) 테이블1 - 티스토리와 연동/ 상태:등록

      es - 동작에 따른 로깅