Soft Delete
데이터를 실제로 삭제하지 않고, 삭제된 것처럼 표시만 하는 방식
보통 is_deleted와 같은 플래그를 추가해 이를 관리합니다.
특징:
- 데이터는 여전히 저장소에 남아 있음.
- "삭제됨" 상태를 나타내는 플래그를 이용.
- 데이터를 복구하거나 기록을 추적할 수 있음.
장점
- 복구 가능: 실수로 삭제한 데이터를 복구할 수 있음.
- 이력 관리: 데이터의 삭제 여부를 기준으로 과거 기록 확인 가능.
- 참조 데이터 보호: 외래 키 제약 조건을 위반하지 않고 삭제 처리 가능.
단점
- 스토리지 증가: 삭제된 데이터를 계속 저장하기 때문에 데이터베이스 크기가 커질 수 있음.
- 복잡한 쿼리: "삭제되지 않은 데이터"를 조회하려면 조건을 추가해야 함 (WHERE is_deleted = false).
- 성능 저하: 많은 "삭제된" 데이터를 포함한 테이블에서 조회 성능 저하 가능성.
Hard Delete
데이터를 데이터베이스에서 영구적으로 삭제하는 방식.
특징
- 데이터가 완전히 제거됨.
- 데이터 복구 불가능.
장점
- 간단함: 삭제와 관련된 플래그나 추가 조건이 필요 없음.
- 공간 절약: 삭제된 데이터가 제거되므로 저장소 사용량 감소.
- 성능 향상: 테이블 크기 감소로 인한 성능 향상 가능.
단점
- 복구 불가능: 실수로 데이터를 삭제하면 복구할 수 없음.
- 추적 불가: 삭제된 데이터의 히스토리를 관리할 수 없음.
- 외래 키 문제: 참조 데이터가 남아 있을 경우 삭제 불가.
Soft Delete vs Hard Delete
특징 | Soft Delete | Hard Delete |
삭제 처리 | 플래그로 삭제 상태만 표시 | 데이터베이스에서 완전히 삭제 |
복구 가능성 | 복구 가능 | 복구 불가능 |
스토리지 사용 | 데이터가 남아 있으므로 더 많이 사용 | 삭제로 인해 절약 가능 |
데이터 추적 | 삭제 여부 추적 가능 | 불가능 |
쿼리 복잡성 | 조건 추가 필요 (is_deleted = false) | 간단함 |
외래 키 문제 | 참조 데이터 관리에 유리 | 참조 데이터 삭제 필요 |
사용처 | 데이터 복구가 중요한 경우 (예: 사용자 계정, 주문 기록 등). 데이터 이력을 유지해야 하는 경우 |
데이터가 복구될 필요가 없고, 공간 절약이 중요한 경우 (예: 로그, 임시 데이터 등). 보안 상 삭제된 데이터가 완전히 제거되어야 하는 경우. |
'DB' 카테고리의 다른 글
[DB] 병행 수행과 병행 제어 (0) | 2024.11.25 |
---|---|
[DB] 트랜잭션 회복 기법 (0) | 2024.11.25 |
[DB] 트랜잭션 ACID (0) | 2024.11.23 |
[DB] 데이터베이스 설계 (0) | 2024.11.17 |
[SQL] 트리거 (0) | 2024.06.08 |