Dovremmo mai cancellare dati in un database?

Come tutte queste cose, la risposta è "dipende".

Se è probabile che l'utente desideri che i dati vengano restituiti, i tuoi amici hanno ragione: non si elimina realmente, basta contrassegnare il record come "cancellato". In questo modo, quando l'utente cambia idea, puoi recuperare i dati.

Tuttavia, se i dati cancellati sono più di un certo periodo di tempo (un anno per esempio), potresti decidere di eliminarlo realmente dalle tabelle live, ma tenerlo in una tabella di archivio o anche solo nel backup se il l'utente lo vuole mai indietro. In questo modo puoi mantenere al minimo la quantità di dati (in diretta e cancellati di recente).

Tuttavia, se i dati sono effimeri o facilmente ricreabili potresti decidere di eliminare effettivamente i dati.

Esiste una classe di dati che hai per eliminare - e si tratta di dati personali che l'utente non vuole più possedere. Potrebbero esserci leggi locali (ad esempio nell'UE) che rendono questo requisito obbligatorio (grazie Gavin )

Allo stesso modo potrebbero esserci delle regole che richiedono a non di eliminare i dati, quindi prima di decidere qualsiasi cosa controllare con le autorità di regolamentazione su cosa devi fare per rispettare la legge.

Questo è in realtà un problema significativo per molte aziende. Non c'è modo di determinare in modo pulito quali dati siano effettivamente in uso, quindi rimane nel database. La cancellazione e l'archiviazione dei dati devono essere parte di ogni progetto di sistema di grandi dimensioni, ma raramente lo è. La maggior parte delle aziende convivono con esso, acquistano dischi più grandi e modificano le query e gli indici per mantenere le prestazioni, fino a quando non cambiano i sistemi e quindi passano attraverso un notevole sforzo per identificare i dati correnti e quindi migrano solo quei record nel loro nuovo sistema. / p>

Sì, dovresti eliminare i dati dal tuo database, ma spesso non è semplice dire cosa e quando.

Ci sono già state molte buone risposte a questo che si riducono praticamente a "dipende dalle circostanze" e non posso aggiungere nulla a quelle.

Una cosa che non è stata menzionata, tuttavia, che penso debba essere menzionata, è che non si dovrebbe mai riutilizzare mai le chiavi primarie generate da una sequenza o da un sistema AUTO_INCREMENT.

Quando si elimina un elemento a cui è stata assegnata una chiave primaria da un sistema di questo tipo, nella colonna della chiave primaria rimangono dei vuoti, lasciati dai dati cancellati. C'è una grande tentazione di riassegnare queste lacune a nuovi elementi man mano che vengono aggiunti o, peggio ancora, di mescolare i dati esistenti per dargli un nuovo ID per rimuovere gli spazi vuoti, ma così facendo daranno origine a problemi che mai avere a che fare se hai appena lasciato le chiavi da solo.

Supponiamo che tu mantenga un database di stampanti per la gestione dei materiali di consumo di riordino. La stampante 13, una vecchia stampante laser, si rompe al di là della riparazione economica, quindi la butti fuori. Nel frattempo, per una ragione non correlata, qualcuno ordina una nuova stampante termica per fare la stampa di codici a barre nel magazzino e quella stampante arriva prima della sostituzione della stampante 13. L'amministratore registra quella nuova stampante nel database e, poiché 13 è ora libera e stai riciclando gli ID, la nuova stampante termica viene assegnata 13 come ID.

Ora qualcuno ti dice che la stampante 13 è quasi senza inchiostro. Ti ricordi che la stampante 13 è una stampante laser, quindi non ti preoccupare di cercarlo nel database e devi ordinare un toner. Solo tu hai effettivamente bisogno di ordinare un pacchetto di inchiostro termico perché la stampante 13 non è più una stampante laser. Quando arriva la cartuccia del toner, non è possibile utilizzarlo perché è la ricarica di inchiostro sbagliata per la stampante, non è possibile stampare altri codici a barre e non è possibile spedire alcun ordine in attesa di essere spedito.

Peggio ancora, cosa succede se elimini la stampante 13 e mischia tutte le stampanti che vengono dopo di essa per riempire il vuoto? La stampante 14 (una vecchia matrice di punti decrepita) diventa la stampante 13, la stampante 15 diventa la stampante 14 e così via.

Tutte le stampanti hanno etichette su di esse in modo che possano essere incrociate con il database, ma ora tutte le etichette non sono aggiornate. Dovrai andare in giro, localizzare tutte le stampanti del business (che potrebbero essere incluse in centinaia!) E relabelarle. Non è un uso efficace del tempo. Ed è anche un processo soggetto a errori e cosa succede se non viene mai fatto? Qualcuno chiama per dire che la stampante 14 si è guastata e ha bisogno di essere riparata con urgenza, quindi lo si guarda e si scopre che la stampante 14 è una stampante a getto d'inchiostro in ricezione. Solo perché hai rimescolato gli ID, è in realtà la stampante ad aghi che ha bisogno di essere riparata con urgenza. Il tizio che ha chiamato il problema è rimasto appeso, mentre l'addetto alla reception ha un addetto al supporto tecnico che non ha mai chiamato per montare una stampante che non sia rotta.

Si dovrebbe pensare agli ID assegnati da un sistema di auto-incremento come permanenti, che sono immutabili e non possono essere riutilizzati, anche se la cosa a cui si riferisce l'ID cessa di esistere. Alcune persone sostengono di non voler preoccuparsi degli ID in via di esaurimento, ma anche con i sistemi a 32 bit e gli ID firmati, sono ancora disponibili circa 2 miliardi di ID. Se è possibile rendere la colonna ID senza segno, questo raddoppia a 4 miliardi e nei sistemi a 64 bit il numero di ID disponibili è letteralmente maggiore del numero di stelle nel cielo. Non hai intenzione di rimanere senza ID.

Molte buone risposte qui già. Voglio solo aggiungere una situazione che nessuno ha ancora menzionato:

Dati sensibili . Se l'utente lo elimina, è meglio cancellarlo!

Una situazione molto comune che viene in mente è cambiare / reimpostare la password. Non si vorrebbe memorizzare vecchie password (anche se sono hash, salate ecc.) Nel proprio database. Gli utenti potrebbero utilizzare le loro vecchie (e cattive) password su altri siti.

Inoltre, quando si tratta di leggi relative a quanto tempo è possibile memorizzare certi tipi di dati, naturalmente, le eliminazioni software non verranno eseguite. Devi effettivamente cancellarlo.

Quindi mi chiedo: l'utente (o qualcun altro, per esempio il governo) si arrabbierà se faccio credere che i dati siano stati cancellati, ma in effetti ho ancora capito e posso ripristinarlo in qualsiasi tempo?

Generalmente non rimuovo i dati dell'utente nei miei database. Li contrassegno per essere nascosto. Troppo spesso un utente cancella qualcosa accidentalmente e ha bisogno di sostituirlo facilmente. Aiuta anche a mantenere l'integrità referenziale per i dati correlati. Funziona per database di dimensioni medio-piccole. Nei sistemi in cui le prestazioni sono pesantemente influenzate da questa decisione, vengono gestite in modi speciali, ad es. tabelle di archivio, backup automatici, ecc.

Scartiamo i dati di back-end secondo necessità, ad es. dati di sessione del sito Web scaduti e informazioni sui log precedenti. Non ha senso tenerli per sempre.

Come al solito, però, la risposta esatta dipende molto dalla situazione specifica.

Ho lavorato a una domanda di Foreign Exchange per un paio di anni in cui è venuto fuori. I dati raccolti dall'applicazione nel corso degli anni hanno avuto un impatto sulle prestazioni (ad esempio esponenziale).

Dopo che abbiamo fatto quello che potevamo in termini di codice, abbiamo proposto al managegement di archiviare i dati più vecchi di un anno. Hanno verificato il concetto (questioni legali) e fortunatamente siamo stati in grado di farlo. Così abbiamo eliminato, ma abbiamo anche archiviato i dati in modo che le aziende continuassero a pubblicare i loro rapporti ecc.

Un'altra situazione rispetto a quella presentata è quando i dati vengono cancellati, ma i registri delle operazioni eseguite nel database (cancellazione inclusa) vengono archiviati negli archivi per un lungo periodo di tempo. Lo scopo principale di questo è l'implementazione di un sistema di rollback per le date passate, ma può anche essere usato per archiviare in qualche modo i dati cancellati (che vengono cancellati dal database, ma archiviati negli archivi).

Archiviare archivi di dati cancellati non sarebbe un grande affare. Le grandi aziende possono anche archiviare versioni di codice e molte altre informazioni (per non parlare di materiale non tecnico) quindi archiviare grandi quantità di dati è per loro qualcosa di solito.

Nella maggior parte dei casi è necessario conservare i dati solo nel caso in cui sia necessario in futuro. L'azienda per cui lavori potrebbe voler esaminare i dati storici per basare le loro decisioni su cui guidare la società in una determinata direzione.

Dovresti aggiungere colonne "Date_Time_Removed" a ogni tabella e poi, invece di eliminare fisicamente la / e riga / e, imposta una data e un'ora in cui la riga è stata praticamente eliminata. Quindi, nelle stored procedure o sql, verrà calcolato nella colonna "Date_Time_Removed", ad es. seleziona blah da tabella1 dove date_time_removed è null

Ovviamente le righe che sono state accidentalmente aggiunte a un database dovrebbero essere rimosse permanentemente, specialmente i dati di test.

Mantenendo tutti i dati legittimi devi anche scegliere di utilizzare il tuo database per il magazzinaggio in futuro.