레코드를 실제로 또는 물리적으로 삭제하는 것과 반대로 레코드의 논리적 / 소프트 삭제 (즉, 레코드가 삭제되었음을 나타내는 플래그 설정)를 수행하면 어떤 이점이 있습니까?
이것이 일반적인 관행입니까?
안전한가요?
답변
장점은 기록을 유지하고 (감사에 적합), 삭제하려는 행을 참조하는 데이터베이스의 다양한 다른 테이블을 통해 계단식으로 삭제하는 것에 대해 걱정할 필요가 없다는 것입니다. 단점은 플래그를 고려하기 위해보고 / 표시 방법을 코딩해야한다는 것입니다.
그것이 일반적인 관행 인 한-나는 예라고 말하고 싶지만, 사용 여부는 비즈니스 요구에 달려 있습니다.
편집 : 또 다른 단점에 대한 생각-테이블에 고유 인덱스가있는 경우 삭제 된 레코드는 여전히 “하나”레코드를 차지하므로 그 가능성을 중심으로 코딩해야합니다 (예 : 고유 인덱스가있는 사용자 테이블). 사용자 이름; 삭제 된 레코드는 새 레코드에 대한 삭제 된 사용자 사용자 이름을 계속 차단합니다.이 문제를 해결하려면 삭제 된 사용자 이름 열에 GUID를 추가 할 수 있지만 권장하지 않는 매우 엉뚱한 해결 방법입니다. 아마도 그런 상황에서는 그렇게 될 것입니다. 사용자 이름이 사용되면 절대로 바꿀 수 없다는 규칙을 갖는 것이 좋습니다.)
답변
논리적 삭제가 일반적인 관행입니까? 예, 여러 곳에서 이것을 보았습니다. 안전한가요? 그것은 정말로 당신이 그것을 삭제하기 전의 데이터보다 덜 안전합니까?
제가 기술 책임자 였을 때 저는 우리 팀이 모든 데이터를 보관할 것을 요구했습니다. 당시에는 요구 사항이 무엇인지 몰랐지만 그 모든 데이터를 사용하여 다양한 BI 애플리케이션을 구축 할 것이라는 것을 당시에는 알고있었습니다. 있다. 감사, 문제 해결 및보고의 관점에서는 좋았지 만 (B2B 거래를위한 전자 상거래 / 도구 사이트였으며 누군가 도구를 사용했다면 나중에 계정이 꺼져도 기록하고 싶었습니다), 몇 가지 단점이있었습니다.
단점은 다음과 같습니다 (이미 언급 된 다른 항목 제외).
- 모든 데이터를 보관하는 성능 시사점, 다양한 아카이빙 전략을 개발합니다. 예를 들어 애플리케이션의 한 영역은 일주일에 약 1Gb의 데이터를 생성하는 데 가까워졌습니다.
- 데이터 유지 비용은 시간이 지남에 따라 증가하지만 디스크 공간은 저렴하지만 온라인 및 오프라인 모두에서 테라 바이트 단위의 데이터를 유지하고 관리하기위한 인프라의 양은 많습니다. 중복성을 위해 많은 디스크가 필요하고 백업이 신속하게 이동하는지 확인하는 데 사람들의 시간이 걸립니다.
논리적, 물리적 삭제 또는 보관을 사용하기로 결정할 때 다음과 같은 질문을합니다.
- 테이블에 다시 삽입해야 할 수있는 데이터입니다. 예를 들어 사용자 계정을 활성화하거나 비활성화 할 수 있으므로 사용자 계정이이 범주에 해당합니다. 이 경우 논리적 삭제가 가장 적합합니다.
- 데이터 저장에 내재적 가치가 있습니까? 그렇다면 얼마나 많은 데이터가 생성 될 것입니다. 이것에 따라 논리적 삭제를 수행하거나 보관 전략을 구현합니다. 논리적으로 삭제 된 레코드는 항상 보관할 수 있습니다.
답변
조금 늦을 수도 있지만 논리적 / 소프트 삭제에 대한 Pinal Dave의 블로그 게시물을 모두 확인하는 것이 좋습니다 .
나는 이런 종류의 디자인 [소프트 삭제]이 전혀 마음에 들지 않습니다. 저는 필요한 데이터 만 단일 테이블에 있어야하고 쓸모없는 데이터는 보관 된 테이블로 이동해야하는 아키텍처를 굳게 믿습니다. isDeleted 열을 따르는 대신에 주문이있는 테이블과 삭제 된 주문이있는 다른 두 개의 테이블을 사용하는 것이 좋습니다. 이 경우 두 테이블을 모두 유지해야하지만 실제로 유지 관리가 매우 쉽습니다. isDeleted 열에 UPDATE 문을 쓸 때 다른 테이블에 INSERT INTO를 쓰고 원래 테이블에서 DELETE하십시오. 상황이 롤백 인 경우 다른 INSERT INTO 및 DELETE를 역순으로 작성하십시오. 실패한 트랜잭션이 걱정된다면이 코드를 TRANSACTION으로 감싼다.
위에서 설명한 상황에서 작은 테이블 대 큰 테이블의 장점은 무엇입니까?
- 더 작은 테이블은 유지하기 쉽습니다.
- 인덱스 다시 작성 작업이 훨씬 빠릅니다.
- 아카이브 데이터를 다른 파일 그룹으로 이동하면 기본 파일 그룹의로드가 감소합니다 (모든 파일 그룹이 다른 시스템에 있음을 고려). 이렇게하면 백업 속도도 빨라집니다.
- 더 작은 크기로 인해 통계가 자주 업데이트되며 이는 리소스 집약적입니다.
- 인덱스의 크기가 작아집니다.
- 테이블 크기가 작을수록 테이블 성능이 향상됩니다.
답변
저는 NoSQL 개발자이고, 마지막 직장에서 누군가에게 항상 중요한 데이터로 작업했는데, 생성 된 당일에 실수로 삭제 된 경우 마지막 백업에서 찾을 수 없었습니다. 어제! 그런 상황에서 소프트 삭제는 항상 그날을 저장했습니다.
타임 스탬프를 사용하여 소프트 삭제를 수행하고 문서가 삭제 된 날짜를 등록했습니다.
IsDeleted = 20150310 //yyyyMMdd매주 일요일에는 프로세스가 데이터베이스를 탐색하고 IsDeleted 현장을 . 현재 날짜와 타임 스탬프의 차이가 N 일보다 크면 문서가 영구 삭제 된 것입니다. 일부 백업에서 문서를 계속 사용할 수 있다는 점을 고려하면 안전하게 수행 할 수 있습니다.
편집하다: 이 NoSQL 사용 사례는 데이터베이스에서 생성되는 대용량 문서에 대한 것입니다. 매일 수십 또는 수백 개가 생성되지만 수천 또는 수백만 개는 아닙니다. 일반적으로 워크 플로 프로세스의 상태, 데이터 및 첨부 파일이있는 문서였습니다. 이것이 사용자가 중요한 문서를 삭제할 가능성이있는 이유입니다. 이 사용자는 관리자 권한이있는 사람이거나 문서의 소유자 일 수 있습니다.
TL; DR 내 사용 사례는 빅 데이터가 아닙니다. 이 경우 다른 접근 방식이 필요합니다.
답변
내가 사용한 한 가지 패턴은 미러 테이블을 만들고 기본 테이블에 트리거를 연결하는 것이므로 모든 삭제 (및 원하는 경우 업데이트)가 미러 테이블에 기록됩니다.
이를 통해 삭제 / 변경된 레코드를 “재구성”할 수 있으며 기본 테이블에서 하드 삭제하고 “정리”상태로 유지할 수 있습니다. 또한 “실행 취소”기능을 생성 할 수 있으며 날짜, 시간도 기록 할 수 있습니다. , 미러 테이블에서 작업을 수행 한 사용자 (마녀 사냥 상황에서 매우 유용함).
다른 장점은 미러 테이블의 레코드를 포함하는 문제를 고의로 수행하지 않는 한 기본 레코드를 쿼리 할 때 실수로 삭제 된 레코드를 포함 할 가능성이 없다는 것입니다 (라이브 및 삭제 된 레코드를 표시 할 수 있음).
또 다른 장점은 미러 테이블을 독립적으로 제거 할 수 있다는 것입니다. 실제 외래 키 참조가 없어야하기 때문에 소프트 삭제를 사용하지만 여전히 다른 테이블에 대한 참조 연결이있는 기본 테이블에서 제거하는 것과 비교할 때 비교적 간단한 작업입니다.
다른 장점은 무엇입니까? -프로젝트를 진행하는 코더가 많고, 기술과 세부 수준에 대한주의가 혼합 된 데이터베이스에서 읽기를 수행하는 경우, 그중 한 명이 삭제 된 것을 포함하지 않기를 바라며 밤을 지날 필요가 없습니다. 기록 (웃음, 삭제 된 기록을 포함하지 않음 = True). 고객이 사용 가능한 현금 포지션을 과장해서 말한 다음 (즉, 거래 시스템에서와 같이) 주식을 사러가는 것과 같은 결과가 발생합니다. 초기 “오버 헤드”가 조금 더 많더라도 강력한 솔루션의 가치를 매우 빠르게 찾을 수 있습니다.
예외 :
-가이드로 사용자, 카테고리 등과 같은 “참조”데이터에 대해서는 소프트 삭제를 사용하고 “사실”유형 데이터 (예 : 트랜잭션 내역)에 대해서는 미러 테이블에 하드 삭제를 사용하십시오.
답변
저는 일반적으로 논리적 삭제를 사용합니다. ‘삭제 된’데이터를 보관 된 테이블 (필요한 경우 검색 할 수 있음)에 간헐적으로 보관하여 애플리케이션 성능에 영향을 미치지 않을 때 잘 작동합니다.
감사를받는 경우에도 데이터가 남아 있기 때문에 잘 작동합니다. 물리적으로 삭제하면 사라집니다 !
답변
저는 특히 LOB (기간 업무) 응용 프로그램이나 사용자 계정의 컨텍스트에서 논리적 삭제를 좋아합니다. 내 이유는 간단합니다. 사용자가 더 이상 시스템을 사용하지 못하도록하는 경우가 많지만 (계정이 삭제 된 것으로 표시됨) 사용자를 삭제하면 모든 작업을 잃게됩니다.
또 다른 일반적인 시나리오는 사용자가 삭제 된 후 잠시 동안 다시 생성 될 수 있다는 것입니다. 사용자가 데이터를 다시 만들지 않고 삭제하기 전의 모든 데이터를 표시하는 것이 훨씬 더 좋은 경험입니다.
일반적으로 사용자를 삭제하는 것은 사용자를 무기한 “정지”하는 것으로 생각합니다. 그들이 합법적으로 돌아와야 할 때를 알 수 없습니다.
