.case(일정 기간동안 게시글 노출여부)

고민

• 특정 목록을 일정 기간동안만 노출하고 싶을 때의 설계 방향에 대해 고민해보자.

결론

• 테이블 설계할때 시간 필드(startDate, endDate)가 꼭 필요한지 노출여부가 필요할지를 판단하면 된다.
• 배치를 이용하는 방법은 데이터의 시간텀이 크고(하루이상이나) 노출여부필드가 반드시 필요할 때 쓰인다. 
• 날짜 필드를 이용하는 방법은 실시간성이 중요하고 좀 더 간편하게 방법으로 사용하고 싶을 때 쓰면 좋을거 같다.

접근방법

배치를 이용하는 경우

• 장점
  • 캐쉬반영이 쉽다. 배치에서 노출여부가 변경되었을때를 evict시점을 정할 수 있다.
• 단점
  • 반영 속도 측면: 배치의 실행시간 간격만큼 노출여부가 늦게 발생한다. 배치가 1시간마다 돌면 1시간의 텀을 두고 노출여부가 변경되고 배치가 1분만다 돌면 1분 텀으로 노출여부가 변경이 된다.

날짜 필드를 이용하는 경우

• 게시글 자체에 startDate, endDate 필드를 만들어 둔다.
• 목록을 조회할때마다 현재 시간을 파라미터(now: 현재시간을 담은 변수)로 하여 startDate <= now && now < endDate로 조회한다.
• 장점
  • 반영 속도 측면: 따로 배치를 돌리지 않아도 리스트에서 자동적으로 제거 된다. 실시간으로 반영된다.
  • 상태 값도 관리할 필요없다. 노출인지 아닌지에 대한 exposeYn or userYn 등등의 필드를 사용해서 관리하지 않아도 된다.
• 단점
  • 캐쉬를 걸기가 상당히 어렵다. evict시점이 데이터에 의존하고 있어서 evict를 명시적으로 해줄 수가 없고 따라서 캐쉬가 있다면 캐쉬시간에 의존해서 반영이 된다.

 

영구적으로 저장할 데이터처리도 생각해볼 것

- 날짜를 무한정으로 줄것인지 날짜를 null로 세팅할 것인지

 

예약 노출이 필요한 스펙에서 아래와 같이 구현해도 깔끔해진다.
- 무조건 노출시 startDate, endDate를 null로 하고 예약여부 false

- 예약 노출시 예약여부 true, startDate, endDate는 맞게 세팅

- 노출 해제시 해당 row삭제

 

 

노출여부와 노출시간으로 동시에 관리해야하는 경우, 두 요소에 우선순위가 있어야한다.

- 노출시간이 더 강한 요소라 작용할지, 노출여부가 더 강한 요소로 작용할지를 정해야한다.

- 나같은 경우, 노출여부를 사용자가 변경할 수 있었기 때문에 노출여부에 따라 노출시간을 조정하도록 하였다.

  - 노출을 해제하는 순간 노출시간의 종료시간을 해제한 순간으로 변경하는 것이다.