Soft Delete VS Hard Delete 상황별 비교
앞서 Soft Delete와 Hard Delete에 대해 살펴봤습니다
두 Delete 전략중 어떤 전략을 사용하는 것이 나을지 상황별로 정리했습니다
설정 및 구현 난이도
Soft Delete는 삭제 플래그를 설정하는 간단한 UPDATE 연산으로 구현되기 때문에, 구현이 매우 쉽습니다
반면에 Hard Delete는 데이터를 실제로 삭제하고 추적 및 감사를 위한 별도의 감사 테이블로 데이터를
옮기는 과정이 필요해 상대적으로 복잡합니다
따라서 설정 및 구현 난이도 측면에서는 Soft Delete가 우위를 갖습니다
데이터 디버깅
Soft Delete는 삭제 플래그를 통해 데이터를 유지하기 때문에 디버깅이 용이합니다
Hard Delete도 감사 테이블을 활용한다면 데이터를 유지할 수는 있기 때문에, 디버깅이 가능합니다
따라서 데이터 디버깅 측면에서는 우위를 가릴 수 없습니다
데이터 복원 용이성
Soft Delete는 삭제 플래그를 설정/해제 하는 방식이라 데이터 복구가 쉽습니다
Hard Delete는 실제 삭제된 데이터를 복구해야하기 상대적으로 어렵습니다
따라서 데이터 복원 용이성 측면에서는 Soft Delete가 우위를 갖습니다
데이터 조회 성능
Soft Delete 방식을 사용할 경우, 삭제 플래그에 대한 조회 조건을 추가해야합니다
이 조건을 누락하면 데이터 무결성 문제가 발생할 수 있습니다
반면에 Hard Delete는 해당 조건을 추가할 필요가 없습니다
조건이 추가될 수록, 애플리케이션 성능은 저하됩니다
만약 Join 연산이 추가된다면 복잡한 조건이 반복되고, 조회 성능은 더욱 저하됩니다
따라서 데이터 조회 성능 측면에서는 Hard Delete가 우위를 갖습니다
SQL 작업 성능
Soft Delete는 단순한 UPDATE 연산을 수행하기 때문에,
실제 데이터를 삭제하고 감사 테이블로 옮겨야하는 Hard Delete보다 작업 속도가 약간 더 빠릅니다
또한 일반적으로 DELETE가 UPDATE보다 성능적으로 좋지 않습니다
따라서 SQL 작업 성능 측면에서는 Soft Delete가 우위를 갖습니다
데이터베이스 기능과의 호환성
Soft Delete는 유니크 인덱스를 유지하거나 ON DELETE CASCADE와 같은
데이터베이스의 편리한 기능을 사용하는데 제한적입니다
유니크 인덱스의 경우, 실제로 데이터가 삭제된 것이 아니기 때문에, 사용에 제약이 존재합니다
또한, DELETE ON CASCADE도 부모 테이블의 테이블을 논리적으로만 삭제하는 것이기 때문에
자식 테이블에 영향을 주지 않습니다
따라서 데이터베이스 기능과의 호환성 측면에서는 Hard DELETE가 우위를 갖습니다
결론
반드시 Soft Delete가 좋은 것은 아닙니다
상황에 따라 Hard Delete가 좋은 경우도 존재합니다
따라서 개발중인 서비스의 상황에 맞춰 적절한 DELETE 방식을 선택하는 것이 권장됩니다
참고
