인프런 커뮤니티 질문&답변
소프트 딜리트 정책에서 유니크 컬럼 중복 방지 전략
작성
·
56
0
유니크 제약조건에 대해 질문드립니다.
예를 들어 핸드폰 번호당 계정을 하나만 가질 수 있어서 핸드폰 컬럼을 유니크제약을 걸었습니다.
특정 회원이 탈퇴할 때 하드 딜리트가 아니라 소프트 딜리트를 하는 정책일 경우, 탈퇴 했던 유저가 다시 가입하게되면 어떻게 해줘야할까요.?
그럼 결국 유니크 제약을 디비에서 없애고, 애플리케이션 단에서 제어를 해야할까요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 우지원님.
소프트 딜리트를 사용하는 상황에서 유니크 제약 조건을 유지하는 방법은 실무에서 중요한 고려 사항입니다. 소프트 딜리트를 통해 데이터의 역사를 유지하면서도, 유니크한 값을 보장하는 방법에는 몇 가지 전략이 있습니다.
유니크 제약 조건을 유지하면서 소프트 딜리트: 보통의 방법으로는 소프트 딜리트를 표현하는 컬럼(예:
is_deleted)이 필요합니다. 데이터베이스에서는 여러 방법으로 기존의 유니크 제약 조건을 우회할 수 있습니다. 기본적으로 일반적인 데이터베이스에서는 특정 컬럼의 조건에 따라 제약 조건을 다르게 설정할 수 있도록 하는 기능이 제한적일 수 있습니다.애플리케이션 단에서 처리:
- 논리적 삭제: 회원이 탈퇴할 때 해당 데이터를 논리적으로 삭제된 것으로 처리하고(
is_deleted = true) 가입 시점에서는 이 조건을 고려하여 새로운 데이터를 추가하여도 기존의 논리적 삭제된 데이터에 영향을 주지 않도록 처리합니다.
- 대체 함수 및 프로시저 사용: 트리거 등 데이터베이스 기능을 활용하여 유니크 검증이 필요할 경우 소프트 딜리트 컬럼도 포함된 복합 유니크 제약을 사용하거나 DBMS의 특정 기능을 활용하여 삭제 상태를 기반으로 유니크 조건을 해석할 수도 있습니다.
- 논리적 삭제: 회원이 탈퇴할 때 해당 데이터를 논리적으로 삭제된 것으로 처리하고(
대체적 접근 방법:
- 이력 관리 테이블 사용: 소프트 딜리트를 위한 이력 테이블을 별도로 만들어 관리하며, 멤버 테이블에는 추가 이력이 쌓이지 않도록 하는 방식으로 중복을 피할 수도 있습니다.
- 이력 관리 테이블 사용: 소프트 딜리트를 위한 이력 테이블을 별도로 만들어 관리하며, 멤버 테이블에는 추가 이력이 쌓이지 않도록 하는 방식으로 중복을 피할 수도 있습니다.
위의 방법 중 특정한 방법을 선택하여 적용할 수 있으며, 이는 사용하는 DBMS와 프로젝트의 요구 사항에 따라 최적의 방법이 다를 수 있습니다. 이와 관련된 추가적인 논의나 구현의 복잡성을 고려하여 결정해야 합니다.
이와 관련된 기존 사례나 유사 질문은 아래 링크들을 통해 더 찾아보실 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.




