Dovremmo mai cancellare i dati in un database?

Sono nuovo di database e sto cercando di capire i concetti di base. Ho imparato a cancellare i dati in un database. Ma uno dei miei amici mi ha detto che non dovresti mai cancellare i dati in un database. Piuttosto, quando non è più necessario, è meglio contrassegnarlo o contrassegnarlo come "non in uso".

È vero? In tal caso, in che modo una grande azienda come IBM gestirà i propri dati per cento o più anni?

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

Se è probabile che l'utente desideri ricuperare i dati, allora i tuoi amici hanno ragione: non elimini davvero il segno come "eliminato". In questo modo quando l'utente cambia idea è possibile recuperare i dati.

Tuttavia, se i dati eliminati sono più vecchi di un certo periodo di tempo (ad esempio un anno), potresti decidere di eliminarli davvero dalle tabelle live ma di tenerli in una tabella di archivio o anche solo di backup se l'utente dovesse mai desiderare indietro. In questo modo è possibile ridurre al minimo la quantità di dati (attivi e cancellati di recente).

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

Esiste una classe di dati che è necessario eliminare, ovvero i dati personali che l'utente non desidera più conservare. Potrebbero esserci leggi locali (ad es. Nell'UE) che lo rendono un requisito obbligatorio (grazie Gavin )

Allo stesso modo, potrebbero esserci delle regole che richiedono di non cancellare i dati, quindi prima di decidere qualsiasi cosa controlla con le autorità regolatorie cosa devi fare per conformarti alla legge.

Questo è in realtà un problema significativo per molte aziende. Non c'è modo di determinare in modo chiaro quali dati sono effettivamente in uso, quindi si trovano solo nel database. La cancellazione e l'archiviazione dei dati devono far parte di ogni progetto di sistema di grandi dimensioni, ma raramente lo è. La maggior parte delle aziende vive con esso, acquistando dischi più grandi e modificando le proprie query e gli indici per mantenere le prestazioni, fino a quando non cambiano i sistemi e quindi fanno un notevole sforzo per identificare i dati correnti e quindi migrare solo quei record nel loro nuovo sistema.

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 praticamente si riducono a "Dipende dalle circostanze", e non posso aggiungere nulla a queste.

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

Quando si elimina un elemento a cui era stata assegnata una chiave primaria da un tale sistema, ci saranno degli spazi vuoti nella colonna chiave primaria, lasciati dai dati eliminati. C'è una grande tentazione di riassegnare questi spazi vuoti 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 facendo così sorgeranno problemi che potresti non dovrai mai fare i conti se hai lasciato le chiavi da sole.

Supponi di conservare un database di stampanti per la gestione dei materiali di consumo riordinati. La stampante 13, una vecchia stampante laser, si rompe al di là della riparazione economica in modo da buttarla fuori. Nel frattempo, per un motivo non correlato, qualcuno ordina una nuova stampante termica per eseguire la stampa di codici a barre nel magazzino e quella stampante arriva prima della sostituzione per la stampante 13. L'amministratore registra quella nuova stampante nel database e, poiché 13 è ora gratuito e stai riciclando gli ID, la nuova stampante termica riceve 13 come ID.

Ora qualcuno ti dice che la stampante 13 ha quasi esaurito l'inchiostro. Ricordi che la stampante 13 è una stampante laser, quindi non ti preoccupi di cercarla nel database e fai un ordine per una cartuccia di toner. Solo in realtà era necessario ordinare un pacchetto di inchiostri termici perché la stampante 13 non è più una stampante laser. Quando arriva la cartuccia del toner, non è possibile utilizzarla perché è una ricarica di inchiostro errata per la stampante, non è possibile stampare altri codici a barre e non è possibile spedire ordini in attesa di essere spediti.

Ancora peggio, cosa succede se si elimina la stampante 13 e si mescolano tutte le stampanti che la seguono per riempire il vuoto? La stampante 14 (qualche 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 loro in modo che possano essere incrociate con il database, ma ora tutte le etichette non sono aggiornate. Dovrai andare in giro, individuare tutte le stampanti del settore (che potrebbero incorrere in centinaia!) E rietichettarle. Non è certo un uso efficace del tempo. Ed è anche un processo soggetto a errori, e cosa succede se non viene mai eseguito? Qualcuno chiama per dire che la stampante 14 si è guastata e deve essere riparata urgentemente, quindi la guardi e scopri che la stampante 14 è una stampante a getto d'inchiostro in ricezione. Solo perché hai mescolato gli ID in giro, in realtà è la stampante a matrice di punti che deve essere riparata urgentemente. Il tizio che ha chiamato il problema viene lasciato in sospeso, mentre l'addetto alla reception ha un addetto all'assistenza tecnica che non ha mai chiesto di alzare per riparare una stampante che non era rotta.

Dovresti considerare gli ID assegnati da un sistema di auto-incremento come permanenti, sono immutabili e non possono essere riutilizzati, anche se la cosa a cui si riferisce l'ID cessa di esistere. Alcune persone sostengono che non vogliono preoccuparsi degli ID in esaurimento, ma anche con sistemi a 32 bit e ID firmati, ci sono ancora 2 miliardi di ID disponibili. Se riesci a rendere non firmata la colonna ID, questo raddoppia a 4 miliardi e su sistemi a 64 bit il numero di ID disponibili è letteralmente maggiore del numero di stelle nel cielo. Non finirai gli ID.

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

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

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

Inoltre, quando si tratta di leggi su quanto tempo è consentito archiviare determinati tipi di dati, ovviamente non lo faranno le eliminazioni automatiche. Devi effettivamente cancellarlo.

Quindi mi chiedo: l'utente (o qualcun altro, ad esempio il governo) sarà pazzo se gli faccio credere che i dati siano stati cancellati, ma in realtà li ho ancora e li posso ripristinare in qualsiasi momento?

In genere non rimuovo i dati dell'utente nei miei database. Li contrassegno per essere nascosti. Troppo spesso un utente elimina qualcosa per errore e deve essere sostituito facilmente. Aiuta anche a mantenere l'integrità referenziale per i dati correlati. Funziona con database di dimensioni da piccole a moderate. Nei sistemi in cui le prestazioni sono fortemente influenzate da questa decisione, vengono gestite in modi speciali, ad esempio tabelle di archivio, backup automatizzati, ecc.

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

Come al solito, tuttavia, la risposta esatta dipende davvero dalla situazione specifica.

Ho lavorato su una domanda di cambio per un paio di anni in cui questo è venuto fuori. I dati raccolti dalla domanda nel corso degli anni hanno avuto un impatto sulle prestazioni (diciamo esponenziale).

Dopo aver fatto ciò che potevamo in termini di codice, abbiamo proposto alla direzione di archiviare i dati più vecchi di un anno. Hanno verificato il concetto (questioni legali) e fortunatamente siamo stati in grado di farlo. Quindi abbiamo eliminato ma abbiamo anche archiviato i dati in modo che le aziende potessero ancora eseguire i loro rapporti, ecc.

Nella maggior parte dei casi è necessario conservare i dati nel caso in cui siano necessari in futuro. L'azienda per cui lavori potrebbe voler esaminare i dati storici su cui basare le proprie decisioni su cui orientare la compagnia in una certa direzione.

È necessario aggiungere colonne "Date_Time_Removed" a ciascuna tabella e quindi, invece di eliminare fisicamente le righe, impostare una data e un'ora in cui la riga è stata praticamente eliminata. Quindi nelle tue stored procedure o sql dovresti inserire la colonna "Date_Time_Removed", ad esempio selezionare blah dalla tabella1 dove date_time_removed è null

Naturalmente le righe che sono state aggiunte accidentalmente a un database devono essere rimosse in modo permanente, in particolare i dati dei test.

Conservando tutti i dati legittimi devi anche scegliere di utilizzare il tuo database per lo stoccaggio in futuro.

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

La memorizzazione di archivi di dati cancellati non sarebbe un grosso problema. Le grandi aziende possono anche archiviare versioni di codice e molte altre informazioni (per non parlare di cose non tecniche correlate), quindi alla fine la memorizzazione di dati di grandi dimensioni è qualcosa di solito per loro.