Soft Delete 방식에 대해 한번 더 고민해보면 좋을 것 같습니다

[minju412]

📝 Describe

데이터베이스에서 데이터를 삭제할 때 Hard Delete와 Soft Delete 두 가지 방식이 있는데요, 저희 팀에서는 실제 데이터를 삭제하는 것보다 삭제된 데이터임을 표시해두는 Soft Delete 방식을 채택했습니다.

Soft Delete 방식을 사용할 때, 그 단점을 알고 사용하는 것이 좋을 것 같습니다.

Soft Delete 방식의 단점과 그 대안

• Soft Delete의 문제점
  • 비즈니스 로직을 잘 이해하지 못하면 부정확한 데이터(ex.삭제된 데이터 노출)를 만들어낼 수 있습니다.
  • 인덱스, unique 등 제약조건 생성 시 계속 delete 표시에 대한 것을 고려해야 하며 유지관리를 복잡하게 할 수 있습니다.
• Soft Delete의 대안
  • 삭제 데이터 따로 보관 : 과거 데이터에 대한 유지를 해야하는 경우, 별도 삭제 데이터 스토리지에 저장하고, 본래 테이블에서는 Hard Delete
  • Audit log(감사로그)를 이용하여 데이터 변경 기록 저장

출처: Soft Delete 혼란

그렇다면 삭제 일시를 저장하는게 좋을까요 상태를 저장하는게 좋을까요?

1️⃣ status를 저장하는 방식

• 장점 : 다양한 상태를 표시할 수 있다
  • 활성화된 상태 active
  • 숨겨진 상태 hidden
  • 삭제된 상태 deleted
• 단점 : 실수로 건들여졌을 때 updated시간이 덮어써지면서 삭제 일시가 사라지는 문제 발생 가능

2️⃣ 삭제 일시를 저장하는 방식

• 장점 : 의도가 명확하다
• 단점 : 다양한 상태를 나타낼 수 없다

✅ Tasks

• Sofe Delete 방식의 단점과 대안 알아두기
• 삭제된 데이터임을 표시하는 방법 정하기

🙋🏻 More

하나, 둘, 셋 화이팅

[hookim]

Hard Delete VS Soft Delete Hard Delete의 장점은 다음과 같네요

1. 쿼리가 직관적이고 단순하다.
2. 실제 데이터를 삭제하니까 데이터 용량을 효율적으로 관리할 수 있다.

그러기 때문에 보안과 관련되거나 중요하지 않은 일회성 데이터에 대해서는 Hard Delete정책을 시행할 수 있다고 하네요.

[chwangmin]

상태를 나타내는 방식이 좋을 거 같습니다. 삭제가 됬는 지 확인하는 tiny_int or boolean이 Date를 확인하는 것 보다 더 직관적이고, 더 빠르게 확인 할 수 있을 것이라고 생각하기 때문입니다.

참고 아래는 hard delete, soft delete 속도 분석 글입니다. https://github.com/sinbom/implement-soft-delete-hibernate

[hookim]

논점으로 돌아가자면 만약 전체 데이터에서 삭제된 데이터의 비율이 적다면 공간 낭비가 심할 것 같습니다. 현재 활성화된 데이터들이 더 많은 경우 해당 데이터들은 삭제일시 필드를 사용하지 않을 것이기 때문입니다. 과연 삭제 비율이 어느정도 될지에 대해서 고민을 해보면 좋을 것 같습니다.