silvergoni.builder()

고민 게시물에 대한 등록과 해제 및 재등록이 있는 경우 처리날짜를 어떻게 기록하면 좋을까. 결론 기획에 따라 방향을 정한다. 사실 이런 변경 테이블 데이터 변경이 일어난다면 로그 플랫폼을 분리해서 관리하는 3번이 가장 이상적으로 생각한다. 처음 구현이 복잡한데 이후로 처리할 잡다구리한 일들이 적어진다. 접근방법 하나의 테이블에서 관리 등록일/ 해제일/ 필드를 만든다. 등록하면 등록일에, 해제하면 해제일에 데이터를 저장한다. 재등록하면 기존 목록에서 등록일만 있는(해제일이 없고) 있는 목록이 있는지 확인한다. 없다면 등록을 허용한다. 이렇게 되면 하나의 주제에 대해서 여러개의 목록이 생길 수 있다. ex) 티스토리와 연동/ 등록일:2021-01-01/ 해제일:2021-01-10 티스토리와 연동/ 등록일:2..

고민 특정 목록을 일정 기간동안만 노출하고 싶을 때의 설계 방향에 대해 고민해보자. 결론 테이블 설계할때 시간 필드(startDate, endDate)가 꼭 필요한지 노출여부가 필요할지를 판단하면 된다. 배치를 이용하는 방법은 데이터의 시간텀이 크고(하루이상이나) 노출여부필드가 반드시 필요할 때 쓰인다. 날짜 필드를 이용하는 방법은 실시간성이 중요하고 좀 더 간편하게 방법으로 사용하고 싶을 때 쓰면 좋을거 같다. 접근방법 배치를 이용하는 경우 장점 캐쉬반영이 쉽다. 배치에서 노출여부가 변경되었을때를 evict시점을 정할 수 있다. 단점 반영 속도 측면: 배치의 실행시간 간격만큼 노출여부가 늦게 발생한다. 배치가 1시간마다 돌면 1시간의 텀을 두고 노출여부가 변경되고 배치가 1분만다 돌면 1분 텀으로 노출..

고민 테이블의 특성마다 다르겠지만 삭제를 어떻게 다룰지가 참 늘 고민이다. 결론 raw데이터 테이블이 아닌데 삭제가 필요하다 > 2번 방식: 바로 삭제하기 삭제된 데이터만 따로 관리가 필요하다. > 3번 방식: 삭제전용 테이블로 이동하기 삭제된 데이터를 따로 보진 않지만 복구가능한 컨텐츠다. > 1번 방식: 상태값으로 삭제(노출) 관리하기 접근방법 첫번째로는 상태값을 두고 삭제여부를 표시하는것이다. 이는 리스트 표시할때 신경써야하지만 정말 삭제하지 않고 데이터를 남길 수 있다는 장점이 있다. 복구시에도 기존 리스트와 순서를 맞추어 유지되기도 한다. 두번쨰는 상태값을 저장하지않고 바로 delete해버리고 새로 다시 들어오면 Insert하는것이다. 이런 경우 복구시에 순서를 유지하려면 사실 ai 필드에 의존..

고민 유저가 가진 돈에서 특정 금액을 투입하여 응모를 하는 경우 고려 사항 결론 아래 사항들을 기본으로 고려해보고 추가로 더 필요한게 없을지 생각해본다. 접근방법 주의사항 트랜잭션을 고려, exception고려 유효성 대상에 대한 확인 로그인된 유저인지 ban과 같은 자격을 상실한 유저가 아닌지 대상 국가인지 자신의 돈이 응모액보다 많은지 응모를 할 수 있는 상황인지 응모권이 남아있는지 응모기간인지 대상 유저가 응모할 수 있는지(당첨자 이거나 이미 응모한 경우를 제외하는 경우) 프로세스 금액 차감 로그 남기기 해당 응모권의 수량 변화