Perché la cancellazione di solito è molto più difficile da implementare rispetto all'inserimento in molte strutture di dati?

Riesci a pensare a qualche motivo specifico per cui la cancellazione è di solito significativamente più difficile da implementare rispetto all'inserimento per molte (la maggior parte?) Strutture di dati?

Esempio rapido: elenchi collegati. L'inserimento è banale, ma la cancellazione ha alcuni casi speciali che lo rendono significativamente più difficile. Gli alberi di ricerca binari autobilanciati come AVL e Red-black sono esempi classici di implementazione dolorosa dell'eliminazione.

Vorrei dire che ha a che fare con il modo in cui la maggior parte della gente pensa: è più facile per noi definire le cose in modo costruttivo, il che porta piacevolmente a facili inserimenti.

È più di un semplice stato d'animo; ci sono ragioni fisiche (cioè digitali) per cui la cancellazione è più difficile.

Quando elimini, lasci un buco dove prima c'era qualcosa. Il termine tecnico per l'entropia risultante è "frammentazione". In un elenco collegato, ciò richiede che si "correggi" il nodo rimosso e si distribuisca la memoria che sta utilizzando. Negli alberi binari, provoca uno sbilanciamento dell'albero. Nei sistemi di memoria, la memoria rimane inutilizzata per un po 'se i blocchi appena allocati sono più grandi dei blocchi lasciati indietro dalla cancellazione.

In breve, l'inserimento è più semplice perché puoi scegliere dove inserire. L'eliminazione è più difficile perché non è possibile prevedere in anticipo quale elemento verrà eliminato.

Perché tende ad essere più difficile da eliminare che da inserire? Le strutture di dati sono progettate più pensando all'inserimento che alla cancellazione, e giustamente.

Considera questo: per eliminare qualcosa da una struttura di dati, deve essere lì in primo luogo. Quindi devi prima aggiungerlo, nel senso che al massimo hai tante eliminazioni quante sono le inserzioni. Se ottimizzi una struttura di dati per l'inserimento, avrai la garanzia di ottenere almeno lo stesso vantaggio che se fosse stato ottimizzato per l'eliminazione.

Inoltre, a che serve l'eliminazione sequenziale di ciascun elemento? Perché non chiamare semplicemente una funzione che cancella tutto in una volta (possibilmente semplicemente creando una nuova)? Inoltre, le strutture di dati sono molto utili quando contengono effettivamente qualcosa. Quindi, in pratica, il caso di avere tante eliminazioni quante le inserzioni non sarà molto comune.

Quando ottimizzi qualcosa, vuoi ottimizzare le cose che fa di più e che richiedono più tempo. Nell'uso normale, la cancellazione di elementi di una struttura di dati avviene meno frequentemente dell'inserimento.

Non è più difficile.

Con gli elenchi doppiamente collegati, quando si inserisce, si allocerà la memoria e quindi si collegherà con il nodo head o precedente e con la coda o il nodo successivo. Quando si elimina, si verrà scollegati esattamente dallo stesso, quindi si libererà memoria. Tutte queste operazioni sono simmetriche.

Ciò presuppone che in entrambi i casi si disponga del nodo da inserire / eliminare. (E nel caso dell'inserzione, che hai anche il nodo da inserire prima, quindi in un certo senso, l'inserimento potrebbe essere considerato leggermente più complicato.) Se stai cercando di eliminare non avendo il nodo da eliminare, ma il payload del nodo, quindi ovviamente dovrai prima cercare nell'elenco il payload, ma non è un difetto di eliminazione, vero?

Con alberi bilanciati, lo stesso vale: un albero generalmente ha bisogno di essere equilibrato immediatamente dopo un inserimento e anche immediatamente dopo una cancellazione. È una buona idea provare ad avere solo una routine di bilanciamento e applicarla dopo ogni operazione, indipendentemente dal fatto che si tratti di un inserimento o di una cancellazione. Se stai cercando di implementare un inserimento che lascia sempre l'albero equilibrato, e anche una cancellazione che lascia sempre l'albero equilibrato, senza che i due condividano la stessa routine di bilanciamento, stai complicando inutilmente la tua vita.

In breve, non vi è alcun motivo per cui uno dovrebbe essere più difficile dell'altro, e se lo stai scoprendo, è in effetti possibile che tu sia vittima della tendenza (molto umana) di trovare più naturale pensare costruttivamente che sottrattivamente, il che significa che potresti implementare la cancellazione in un modo più complicato di quanto debba essere. Ma questo è un problema umano. Da un punto di vista matematico, non vi è alcun problema.

In termini di runtime, esaminando il confronto della complessità temporale delle operazioni della struttura dei dati su Wikipedia, si noti che le operazioni di inserimento ed eliminazione hanno la stessa complessità. L'operazione di eliminazione profilata è la cancellazione per indice, in cui si ha un riferimento all'elemento struttura da eliminare; l'inserimento avviene per articolo. Il tempo di esecuzione più lungo per l'eliminazione in pratica è perché di solito hai un elemento da eliminare e non il suo indice, quindi hai anche bisogno di un'operazione di ricerca. La maggior parte delle strutture di dati nella tabella non richiede una ricerca aggiuntiva per un inserto perché la posizione di posizionamento non dipende dall'elemento o la posizione viene determinata implicitamente durante l'inserimento.

Per quanto riguarda la complessità cognitiva, c'è una risposta alla domanda: casi limite. La cancellazione può avere più di questi rispetto all'inserimento (questo deve ancora essere stabilito nel caso generale). Tuttavia, almeno alcuni di questi casi limite possono essere evitati in alcuni progetti (ad es. Avere un nodo sentinella in un elenco collegato).

Oltre a tutti i problemi citati, vi è l'integrità referenziale dei dati. Per costruire in modo più appropriato la struttura dei dati come i database in SQL, l'integrità referenziale Oracle è molto importante.
Per essere sicuro di non distruggerlo accidentalmente molte cose diverse inventate.
Ad esempio, a cascata su delete, che non solo elimina ciò che si tenta di eliminare, ma attiva anche la pulizia dei dati correlati.
Questo ripulisce il database dai dati spazzatura e mantiene intatta l'integrità dei dati.
Ad esempio, hai tabelle con genitori e tipi come record correlati nella seconda tabella.
Dove parent è la tabella principale. Se non si dispone di un'integrità referenziale rafforzata in atto, è possibile eliminare qualsiasi record in qualsiasi tabella e in seguito non si saprà come ottenere informazioni complete sulla famiglia poiché sono presenti dati nella tabella figlio e nulla nella tabella padre.
Questo è il motivo per cui il controllo dell'integrità referenziale non consente di eliminare i record dalla tabella padre fino a quando i record dalla tabella figlio non vengono ripuliti.
Ed è per questo che nella maggior parte delle fonti di dati è più difficile eliminare i dati.