많은 데이터 구조에서 삽입보다 삭제가 구현하기가 더 어려운 이유는 무엇입니까?

많은 (대부분의) 데이터 구조에 대한 삽입보다 삭제가 구현하기가 훨씬 어려운 특정 이유를 생각할 수 있습니까?

빠른 예 : 링크 된 목록. 삽입은 사소한 것이지만 삭제에는 몇 가지 특별한 경우가있어 상당히 어려워집니다. AVL 및 Red-black과 같은 자체 균형 이진 검색 트리는 고통스러운 삭제 구현의 전형적인 예입니다.

나는 그것이 대부분의 사람들이 생각하는 방식과 관련이 있다고 말하고 싶습니다 : 우리가 건설적으로 물건을 정의하는 것이 더 쉬워서 쉽게 삽입 할 수 있습니다.

그것은 단지 마음의 상태 이상입니다. 삭제가 더 어려운 물리적 (즉, 디지털) 이유가 있습니다.

삭제하면 예전의 위치에 구멍이 생깁니다. 결과 엔트로피의 기술 용어는 "조각화"입니다. 연결된 목록에서 제거 된 노드를 "패치"하고 사용중인 메모리를 할당 해제해야합니다. 이진 트리에서는 트리의 균형이 맞지 않습니다. 메모리 시스템에서 새로 할당 된 블록이 삭제로 남겨진 블록보다 큰 경우 메모리가 잠시 동안 사용되지 않습니다.

간단히 말해서 삽입 할 위치를 선택하기 때문에 삽입이 더 쉽습니다. 어떤 항목이 삭제 될지 미리 예측할 수 없으므로 삭제가 더 어렵습니다.

삽입하는 것보다 삭제하기 어려운 이유는 무엇입니까? 데이터 구조는 삭제보다는 삽입을 염두에두고 설계되었습니다.

이것을 고려하십시오-데이터 구조에서 무언가를 삭제하려면 처음에 있어야합니다. 따라서 먼저 추가해야합니다. 즉, 삽입 할 때만 큼 삭제가 많이 발생합니다. 삽입을 위해 데이터 구조를 최적화하면 삭제에 최적화 된 것처럼 최소한의 이점을 얻을 수 있습니다.

또한 각 요소를 순차적으로 삭제하는 데 어떤 용도가 있습니까? 한 번에 모두 지우는 함수를 호출하는 것이 어떻습니까? 또한 데이터 구조는 실제로 무언가를 포함 할 때 가장 유용합니다. 따라서 삽입만큼 삭제가 많은 경우 실제로는 일반적이지 않습니다.

무언가를 최적화 할 때 가장 많이하는 작업과 가장 많은 시간이 걸리는 작업을 최적화하려고합니다. 일반적인 사용법에서 데이터 구조의 요소 삭제는 삽입보다 자주 발생하지 않습니다.

어렵지 않습니다.

이중 연결 목록을 사용하면 삽입 할 때 메모리를 할당 한 다음 헤드 또는 이전 노드, 꼬리 또는 다음 노드와 연결됩니다. 삭제하면 정확히 동일한 연결을 해제 한 다음 메모리를 비 웁니다. 이 모든 작업은 대칭입니다.

이것은 두 경우 모두 삽입 / 삭제할 노드가 있다고 가정합니다. (삽입의 경우, 이전에 삽입 할 노드가 있으므로 삽입이 약간 더 복잡한 것으로 생각 될 수 있습니다.) 삭제할 노드가 아닌 페이로드 를 삭제하려고하면 물론 페이로드에 대한 목록을 먼저 검색해야하지만 삭제의 단점은 아닙니다. 그렇지 않습니까?

균형 잡힌 나무도 마찬가지입니다. 나무는 일반적으로 삽입 직후와 삭제 직후에 균형을 유지해야합니다. 하나의 밸런싱 루틴 만 시도하고 삽입 또는 삭제 여부에 관계없이 각 작업 후에 적용하는 것이 좋습니다. 항상 트리 균형을 유지하는 삽입과 두 트리가 동일한 균형 조정 루틴을 공유하지 않고 항상 트리 균형을 유지하는 삭제를 구현하려고하면 불필요하게 인생이 복잡해집니다.

요컨대, 하나가 다른 하나보다 더 어려워 야 할 이유가 없으며, 그것이 사실이라면, 당신이 생각하는 것이 더 자연스러워지는 (매우 인간적인) 경향의 희생자 일 가능성이 있습니다. 빼기보다 건설적으로, 즉, 필요한 것보다 복잡한 방식으로 삭제를 구현할 수 있음을 의미합니다. 그러나 그것은 인간의 문제입니다. 수학적 관점에서는 문제가 없습니다.

런타임 측면 에서 Wikipedia 의 데이터 구조 작업 시간 복잡도 비교 를 살펴보면 삽입 및 삭제 작업의 복잡도는 동일합니다. 삭제 된 구조 요소에 대한 참조가있는 색인에 의한 삭제가 프로파일 링 된 삭제 조작입니다. 항목 별 삽입입니다. 실제로 삭제 시간이 길어지면 일반적으로 색인이 아닌 삭제할 항목이 있으므로 찾기 작업이 필요하기 때문입니다. 배치 위치가 항목에 의존하지 않거나 삽입 중에 위치가 암시 적으로 결정되므로 테이블의 대부분의 데이터 구조에는 삽입에 대한 추가 찾기가 필요하지 않습니다.

인지 복잡성에 관해서는 질문에 대한 답이 있습니다. 삭제는 삽입보다 더 많은 것을 가질 수 있습니다 (일반적인 경우 아직 설정되지 않았습니다). 그러나 특정 설계에서는 이러한 에지 사례 중 적어도 일부를 피할 수 있습니다 (예 : 링크 된 목록에 센티넬 노드가 있음).

언급 된 모든 문제 외에도 데이터 참조 무결성이 포함됩니다. SQL에서 데이터베이스와 같은 데이터 구조를 가장 적절하게 구축하려면 Oracle 참조 무결성이 매우 중요합니다.
실수로 그것을 발명하지 않은 많은 것들을 파괴하지 않도록하십시오.
예를 들어 삭제시 캐스케이드는 삭제하려는 항목을 삭제할뿐 아니라 관련 데이터 정리를 트리거합니다.
이것은 정크 데이터로부터 데이터베이스를 정리하고 데이터의 무결성을 그대로 유지합니다.
예를 들어 두 번째 테이블에 관련 레코드로 부모와 종류의 테이블이 있습니다.
부모는 메인 테이블입니다. 참조 무결성을 강화하지 않은 경우 모든 테이블에서 레코드를 삭제할 수 있으며 나중에 하위 테이블에 데이터가 있고 상위 테이블에 데이터가 없기 때문에 전체 가족 정보를 얻는 방법을 알 수 없습니다.
따라서 참조 무결성 검사를 통해 하위 테이블의 레코드가 정리 될 때까지 상위 테이블에서 레코드를 삭제할 수 없습니다.
이것이 대부분의 데이터 소스에서 데이터를 삭제하기가 더 어려운 이유입니다.