소프트 삭제를 안 쓰는 경우

1️⃣ 로그성 데이터 (Audit, 로그, 히스토리 테이블)

✔ 예시:

• 사용자 로그인 기록 (login_history)
• 결제 이력 로그 (payment_log)
• 시스템 에러 로그 (error_log)

❌ 소프트 삭제가 불필요한 이유:

• 삭제 자체를 하지 않음 (히스토리로 계속 보관함)
• 삭제하면 의미 없음 → 어차피 로그는 쌓이기만 함

---

2️⃣ 단순 캐시성 테이블

✔ 예시:

• 추천 상품 캐시 테이블 (recommended_items)
• 최근 본 상품 리스트 (recent_viewed_items)

❌ 소프트 삭제가 불필요한 이유:

• 데이터가 짧은 주기로 자주 변경, 만료됨
• 그냥 하드 삭제(DELETE)하거나 TTL로 만료되게 처리하는 게 성능상 좋음

---

3️⃣ 중간 조인 테이블 (Many-to-Many 관계)

✔ 예시:

• user_roles (유저 ↔ 역할)
• post_tags (게시글 ↔ 태그)

❌ 소프트 삭제가 불필요한 이유:

• 단순한 관계 연결 역할만 함
• 삭제하면 다시 삽입하면 되고, 이력 추적이 중요하지 않음
• Soft Delete하면 쿼리가 복잡해지고 성능 저하만 생김

---

4️⃣ 고속 처리용 대용량 테이블

✔ 예시:

• 실시간 알림 테이블 (notifications)
• 임시 업로드 파일 목록

❌ 소프트 삭제가 불필요한 이유:

• 수십만~수백만 건이 자주 insert/delete
• is_deleted = false 같은 조건이 조회 성능을 급격히 저하시킬 수 있음
• 실시간 성능이 중요할 땐 하드 삭제가 효율적

---

5️⃣ 법적/보안상 완전 삭제가 필요한 데이터

✔ 예시:

• GDPR에 따라 "탈퇴한 유저 정보"는 완전 삭제해야 하는 경우
• 민감 정보가 들어간 테이블 (개인정보, 인증서 등)

❌ 소프트 삭제가 불가능한 이유:

• 법적 요구에 따라 물리적으로 데이터 삭제가 필수
• is_deleted = true만 해선 안 되고, 디스크에서 완전히 지워져야 함

---

❗ 보너스: Soft Delete의 단점도 함께 기억하자

항목단점

성능 저하	항상 WHERE is_deleted = false 조건 붙음
복잡한 쿼리	조인, 인덱스, 카운트 쿼리에서 혼란 생길 수 있음
실수 가능성	Soft Delete 된 데이터를 실수로 복구할 수 있음
진짜 삭제는 따로 관리	주기적으로 "물리 삭제 배치" 돌려야 함