.case(삭제 테이블 설계 고려사항)

고민

• 테이블의 특성마다 다르겠지만 삭제를 어떻게 다룰지가 참 늘 고민이다.

결론

• raw데이터 테이블이 아닌데 삭제가 필요하다 > 2번 방식: 바로 삭제하기
• 삭제된 데이터만 따로 관리가 필요하다. > 3번 방식: 삭제전용 테이블로 이동하기
• 삭제된 데이터를 따로 보진 않지만 복구가능한 컨텐츠다. > 1번 방식: 상태값으로 삭제(노출) 관리하기

접근방법

• 첫번째로는 상태값을 두고 삭제여부를 표시하는것이다.
  • 이는 리스트 표시할때 신경써야하지만
  • 정말 삭제하지 않고 데이터를 남길 수 있다는 장점이 있다.
  • 복구시에도 기존 리스트와 순서를 맞추어 유지되기도 한다.
• 두번쨰는 상태값을 저장하지않고 바로 delete해버리고 새로 다시 들어오면 Insert하는것이다.
  • 이런 경우 복구시에 순서를 유지하려면 사실 ai 필드에 의존하기보다는 정렬전용 필드가 하나 더 있어야한다.
  • 데이터가 중복해서 저장할때 많이 썼다.
    • 예를들어 기본 컨텐츠 테이블이 있고 여기서 몇개만 데이터를 뽑아 특정 테이블로 구성하였을때, 어차피 기본 컨텐츠에 기본정보들이 있기에 특정 테이블의 데이터는 바로 지우고 넣고 하는 식으로 진행하였다. 일종의 캐쉬? 테이블을 삭제처리할때 이 방식으로 진행하였다.
• 세번재는 다른 테이블로 삭제된 내용을 이동해두는 방식도 있다.
  • backup테이블이나 delete테이블처럼 삭제된 데이터를 모아두는 방식이다.
  • 데이터를 구분하기도 좋지만 일단 테이블이 2벌씩 존재하고 테이블간의 데이터관리가 1번에 비해 복잡하다.