Eliminazione fisica o logica / soft del record del database?

Qual è il vantaggio di eseguire un'eliminazione logica / temporanea di un record (ad es. Impostare un flag che indica che il record è stato eliminato) rispetto all'eliminazione effettiva o fisica del record?

È questa una pratica comune?

È sicuro?

I vantaggi sono che mantieni la cronologia (utile per l'auditing) e non devi preoccuparti di eseguire un'eliminazione a cascata attraverso varie altre tabelle nel database che fanno riferimento alla riga che stai eliminando. Lo svantaggio è che devi codificare qualsiasi metodo di segnalazione / visualizzazione per tenere in considerazione il flag.

Per quanto riguarda la pratica comune, direi di sì, ma come per qualsiasi cosa, il fatto che tu lo utilizzi dipende dalle tue esigenze aziendali.

EDIT: pensiero di un altro svantaggio: se hai indici univoci sulla tabella, i record eliminati occuperanno ancora il record "uno", quindi devi codificare anche questa possibilità (ad esempio, una tabella utente che ha un indice univoco nome utente; Un record eliminato bloccherebbe comunque il nome utente degli utenti eliminati per i nuovi record. Aggirando questo potresti aggiungere un GUID alla colonna del nome utente eliminato, ma è una soluzione alternativa molto complicata che non consiglierei. Probabilmente in quella circostanza lo farebbe è meglio avere una regola secondo cui una volta utilizzato un nome utente, non può mai essere sostituito.)

Le eliminazioni logiche sono una pratica comune? Sì, l'ho visto in molti posti. Sono al sicuro? Dipende davvero, sono meno sicuri dei dati prima di eliminarli?

Quando ero un Tech Lead, chiedevo al nostro team di conservare ogni pezzo di dati, allora sapevo che avremmo utilizzato tutti quei dati per creare varie applicazioni di BI, anche se all'epoca non sapevamo quali sarebbero stati i requisiti essere. Sebbene ciò fosse positivo dal punto di vista del controllo, della risoluzione dei problemi e dei rapporti (questo era un sito di e-commerce / strumenti per transazioni B2B e se qualcuno utilizzava uno strumento, volevamo registrarlo anche se il suo account è stato successivamente disattivato), aveva diversi aspetti negativi.

Gli svantaggi includono (esclusi altri già menzionati):

1. Implicazioni sulle prestazioni della conservazione di tutti quei dati, Sviluppiamo varie strategie di archiviazione. Ad esempio, un'area dell'applicazione si stava avvicinando alla generazione di circa 1 GB di dati a settimana.
2. Il costo per conservare i dati cresce nel tempo, mentre lo spazio su disco è economico, la quantità di infrastruttura per conservare e gestire terrabyte di dati sia online che offline è molto. Ci vuole molto disco per la ridondanza e il tempo delle persone per garantire che i backup si muovano rapidamente, ecc.

Quando decido di utilizzare eliminazioni logiche, fisiche o archiviazione, mi pongo queste domande:

1. Questi dati potrebbero dover essere reinseriti nella tabella. Ad esempio, gli account utente rientrano in questa categoria poiché potresti attivare o disattivare un account utente. In questo caso, una cancellazione logica ha più senso.
2. C'è un valore intrinseco nella memorizzazione dei dati? In tal caso, quanti dati verranno generati. A seconda di ciò, sceglierei un'eliminazione logica o implementerei una strategia di archiviazione. Tieni presente che puoi sempre archiviare i record eliminati in modo logico.

Potrebbe essere un po 'tardi, ma suggerisco a tutti di controllare il post sul blog di Pinal Dave sull'eliminazione logica / soft:

Semplicemente non mi piace affatto questo tipo di design [eliminazione graduale]. Sono fermamente convinto dell'architettura in cui solo i dati necessari dovrebbero essere in una singola tabella e i dati inutili dovrebbero essere spostati in una tabella archiviata. Invece di seguire la colonna isDeleted, suggerisco di utilizzare due diverse tabelle: una con gli ordini e un'altra con gli ordini cancellati. In tal caso, dovrai mantenere entrambi i tavoli, ma in realtà è molto facile da mantenere. Quando scrivi l'istruzione UPDATE nella colonna isDeleted, scrivi INSERT INTO un'altra tabella e CANCELLA dalla tabella originale. Se la situazione è di rollback, scrivi un altro INSERT INTO e DELETE in ordine inverso. Se sei preoccupato per una transazione non riuscita, racchiudi questo codice in TRANSACTION.

Quali sono i vantaggi della tabella più piccola rispetto a quella più grande nelle situazioni sopra descritte?

• Un tavolo più piccolo è facile da mantenere
• Le operazioni di ricostruzione dell'indice sono molto più veloci
• Spostare i dati dell'archivio in un altro filegroup ridurrà il carico del filegroup primario (considerando che tutti i filegroup si trovano su un sistema diverso) - questo accelererà anche il backup.
• Le statistiche verranno aggiornate frequentemente a causa delle dimensioni inferiori e questo richiederà meno risorse.
• La dimensione dell'indice sarà inferiore
• Le prestazioni della tabella miglioreranno con una dimensione ridotta della tabella.

Sono uno sviluppatore NoSQL e nel mio ultimo lavoro ho lavorato con dati che erano sempre critici per qualcuno, e se sono stati cancellati per sbaglio nello stesso giorno in cui sono stati creati, non sono riuscito a trovarli nell'ultimo backup da ieri! In quella situazione, la cancellazione graduale ha sempre salvato la giornata.

Ho eseguito l'eliminazione graduale utilizzando i timestamp, registrando la data in cui il documento è stato eliminato:

IsDeleted = 20150310  //yyyyMMdd

Ogni domenica, un processo camminava sul database e controllava il IsDeletedcampo. Se la differenza tra la data corrente e il timestamp era maggiore di N giorni, il documento è stato eliminato definitivamente. Considerando che il documento era ancora disponibile su alcuni backup, era sicuro farlo.

EDIT: questo caso d'uso NoSQL riguarda i grandi documenti creati nel database, decine o centinaia ogni giorno, ma non migliaia o milioni. In generale, erano documenti con lo stato, i dati e gli allegati dei processi del flusso di lavoro. Questo era il motivo per cui c'era la possibilità che un utente cancellasse un documento importante. Questo utente potrebbe essere qualcuno con privilegi di amministratore o forse il proprietario del documento, solo per citarne alcuni.

TL; DR Il mio caso d'uso non è stato Big Data. In tal caso, avrai bisogno di un approccio diverso.

Un modello che ho usato è creare una tabella mirror e collegare un trigger sulla tabella primaria, quindi tutte le eliminazioni (e gli aggiornamenti se lo si desidera) vengono registrate nella tabella mirror.

Questo ti permette di "ricostruire" i record cancellati / modificati, e puoi ancora eliminare definitivamente nella tabella primaria e mantenerla "pulita" - permette anche la creazione di una funzione di "annullamento", e puoi anche registrare la data, l'ora e l'utente che ha eseguito l'azione nel tavolo dello specchio (inestimabile nelle situazioni di caccia alle streghe).

L'altro vantaggio è che non vi è alcuna possibilità di includere accidentalmente i record eliminati quando si interroga il primario a meno che non ci si prenda deliberatamente la briga di includere i record dalla tabella mirror (si consiglia di mostrare record live ed eliminati).

Un altro vantaggio è che la tabella mirror può essere eliminata in modo indipendente, poiché non dovrebbe avere riferimenti effettivi a chiave esterna, rendendo questa operazione relativamente semplice rispetto all'eliminazione da una tabella primaria che utilizza eliminazioni soft ma ha ancora connessioni referenziali ad altre tabelle.

Quali altri vantaggi? - ottimo se hai un gruppo di programmatori che lavorano al progetto, che eseguono letture sul database con abilità miste e attenzione ai livelli di dettaglio, non devi rimanere sveglio la notte sperando che uno di loro non abbia dimenticato di non includere cancellati record (lol, Not Include Deleted Records = True), che si traduce in cose come sopravvalutare la posizione di cassa disponibile del cliente con la quale poi vanno a comprare alcune azioni (cioè, come in un sistema di trading), quando lavori con i sistemi di trading, tu scoprirà molto rapidamente il valore di soluzioni robuste, anche se possono avere un po 'più di "overhead" iniziale.

Eccezioni:
- come guida, utilizzare eliminazioni soft per dati "di riferimento" come utente, categoria, ecc. E eliminazioni hard in una tabella mirror per dati di tipo "fact", ovvero cronologia delle transazioni.

Di solito uso le eliminazioni logiche: trovo che funzionino bene quando archivi in ​​modo intermittente anche i dati "cancellati" in una tabella archiviata (che può essere cercata se necessario), quindi non avendo alcuna possibilità di influenzare le prestazioni dell'applicazione.

Funziona bene perché hai ancora i dati se sei mai stato controllato. Se lo elimini fisicamente, non c'è più !

Sono un grande fan dell'eliminazione logica, specialmente per un'applicazione Line of Business o nel contesto degli account utente. Le mie ragioni sono semplici: spesso non voglio che un utente possa più usare il sistema (quindi l'account viene contrassegnato come cancellato), ma se cancellassimo l'utente, perderemmo tutto il suo lavoro e così via.

Un altro scenario comune è che gli utenti potrebbero essere ricreati un po 'dopo essere stati eliminati. È un'esperienza molto più piacevole per l'utente avere tutti i dati presenti come erano prima di essere cancellati, piuttosto che doverli ricreare.

Di solito penso di eliminare gli utenti più come "sospenderli" a tempo indeterminato. Non sai mai quando avranno legittimamente bisogno di tornare.

Quasi sempre elimino gradualmente ed ecco perché:

• puoi ripristinare i dati cancellati se un cliente ti chiede di farlo. Clienti più soddisfatti con eliminazioni soft. Il ripristino di dati specifici dai backup è complesso
• il controllo isdeletedovunque non è un problema, è necessario verificare useridcomunque (se il database contiene dati di più utenti). È possibile applicare il controllo tramite codice, posizionando questi due controlli su una funzione separata (o utilizzare le viste)
• graziosa eliminazione. Gli utenti o i processi che si occupano di contenuto eliminato continueranno a "vederlo" fino a quando non effettueranno l'aggiornamento successivo. Questa è una caratteristica molto desiderabile se un processo sta elaborando alcuni dati che vengono improvvisamente cancellati
• sincronizzazione: se devi progettare un meccanismo di sincronizzazione tra un database e le app mobili, troverai le eliminazioni soft molto più facili da implementare

Ri: "Questo è sicuro?" - dipende da cosa intendi.

Se intendi che cancellando fisicamente impedirai a chiunque di trovare i dati cancellati , allora sì, è più o meno vero; sei più sicuro eliminando fisicamente i dati sensibili che devono essere cancellati, perché ciò significa che sono definitivamente andati dal database. (Tuttavia, renditi conto che potrebbero esserci altre copie dei dati in questione, come in un backup, o nel registro delle transazioni, o una versione registrata in transito, ad esempio uno sniffer di pacchetti - solo perché elimini dal tuo database non garantisco che non è stato salvato altrove.)

Se intendi che eseguendo l'eliminazione logica, i tuoi dati sono più sicuri perché non perderai mai alcun dato , anche questo è vero. Ciò è utile per gli scenari di audit; Io tendo a progettare questo modo perché ammette il fatto fondamentale che una volta che si genera dati, non sarà mai veramente andare via (specialmente se mai avuto la capacità di essere, per esempio, nella cache da un motore di ricerca su Internet). Ovviamente, uno scenario di controllo reale richiede che non solo le eliminazioni siano logiche, ma che anche gli aggiornamenti vengano registrati, insieme all'ora della modifica e all'attore che ha apportato la modifica.

Se intendi che i dati non cadranno nelle mani di nessuno che non dovrebbe vederli, allora dipende totalmente dalla tua applicazione e dalla sua struttura di sicurezza. Sotto questo aspetto, l'eliminazione logica non è più o meno sicura di qualsiasi altra cosa nel database.

Non sono assolutamente d' accordo con l'eliminazione logica perché sei esposto a molti errori.

Prima di tutto le query, ogni query deve occuparsi del campo IsDeleted e la possibilità di errore aumenta con le query complesse.

Secondo la performance: immagina una tabella con 100000 rec con solo 3 attivi, ora moltiplica questo numero per le tabelle del tuo database; un altro problema di prestazioni è un possibile conflitto con nuovi record con vecchi (record eliminati).

L'unico vantaggio che vedo è la cronologia dei record, ma ci sono altri metodi per ottenere questo risultato, ad esempio puoi creare una tabella di logging dove puoi salvare le informazioni: TableName,OldValues,NewValues,Date,User,[..]dove *Valuespossono essere varchare scrivere i dettagli in questo modulo fieldname : value; [..] o memorizzare le informazioni come xml.

Tutto questo può essere ottenuto tramite codice o Trigger ma sei solo UNA tabella con tutta la tua cronologia. Un'altra opzione è vedere se il motore di database specificato è supporto nativo per il rilevamento delle modifiche, ad esempio sul database SQL Server ci sono SQL Track Data Change.

Facevo l'eliminazione temporanea, solo per conservare i vecchi record. Mi sono reso conto che gli utenti non si preoccupano di visualizzare i vecchi dischi tutte le volte che pensavo. Se gli utenti desiderano visualizzare i vecchi record, possono semplicemente visualizzarli dall'archivio o dalla tabella di controllo, giusto? Allora, qual è il vantaggio dell'eliminazione temporanea? Porta solo a dichiarazioni di query più complesse, ecc.

Di seguito sono riportate le cose che ho implementato, prima di decidere di non eliminare più temporaneamente:

1. implementare l'audit, per registrare tutte le attività (aggiungere, modificare, eliminare). Assicurati che non ci sia alcuna chiave esterna collegata al controllo e assicurati che questa tabella sia protetta e che nessuno possa eliminare tranne gli amministratori.

2. identificare quali tabelle sono considerate "tabelle transazionali", che molto probabilmente verranno conservate per molto tempo, e molto probabilmente l'utente potrebbe voler visualizzare i record o i rapporti passati. Per esempio; transazione di acquisto. Questa tabella non dovrebbe solo mantenere l'ID della tabella principale (come dept-id), ma anche mantenere le informazioni aggiuntive come il nome come riferimento (come dept-name) o qualsiasi altro campo necessario per la segnalazione.

3. Implementa il record "attivo / inattivo" o "abilita / disabilita" o "nascondi / mostra" della tabella principale. Quindi, invece di eliminare il record, l'utente può disabilitare / inattivo il record principale. È molto più sicuro in questo modo.

Solo la mia opinione di due centesimi.

Eliminazioni logiche se sono difficili per l'integrità referenziale.

È la cosa giusta da fare quando c'è un aspetto temporale dei dati della tabella (sono validi FROM_DATE - TO_DATE).

In caso contrario, spostare i dati in una tabella di controllo ed eliminare il record.

Il lato positivo:

È il modo più semplice per eseguire il rollback (se possibile).

È facile vedere quale fosse lo stato in un momento specifico.

È abbastanza standard nei casi in cui desideri mantenere una cronologia di qualcosa (ad esempio account utente come menzionato da @Jon Dewees). Ed è sicuramente un'ottima idea se c'è una forte possibilità che gli utenti chiedano l'annullamento delle eliminazioni.

Se sei preoccupato per la logica di filtrare i record eliminati dalle tue query che diventano disordinate e complicano solo le tue query, puoi semplicemente creare visualizzazioni che eseguono il filtro per te e utilizzare le query contro quello. Impedirà la perdita di questi record nelle soluzioni di reporting e simili.

Ci sono requisiti oltre alla progettazione del sistema a cui è necessario rispondere. Qual è il requisito legale o statutario per la conservazione dei dati? A seconda di ciò a cui sono correlate le righe, potrebbe esserci un requisito legale che i dati vengano conservati per un certo periodo di tempo dopo che sono stati "sospesi".

D'altra parte, il requisito può essere che una volta che il record è stato "cancellato", è veramente e irrevocabilmente cancellato. Prima di prendere una decisione, parla con i tuoi stakeholder.

Le app mobili che dipendono dalla sincronizzazione potrebbero imporre l'uso dell'eliminazione logica piuttosto che fisica: un server deve essere in grado di indicare al client che un record è stato (contrassegnato come) eliminato e ciò potrebbe non essere possibile se i record sono stati eliminati fisicamente.

Non lasciano che il database funzioni come dovrebbe, rendendo inutili cose come la funzionalità a cascata.

Per cose semplici come gli inserti, in caso di reinserimento, il codice dietro si raddoppia.

Non puoi semplicemente inserire, invece devi controllare l'esistenza e inserire se non esiste prima o aggiornare il flag di cancellazione se lo fa mentre aggiorna anche tutte le altre colonne ai nuovi valori. Questo è visto come un aggiornamento del registro delle transazioni del database e non un nuovo inserimento che causa registri di controllo imprecisi.

Causano problemi di prestazioni perché le tabelle vengono riempite con dati ridondanti. Gioca con l'indicizzazione soprattutto con l'unicità.

Non sono un grande fan delle eliminazioni logiche.

Per rispondere al commento di Tohid, abbiamo affrontato lo stesso problema in cui volevamo mantenere la cronologia dei record e inoltre non eravamo sicuri se volevamo una is_deletedcolonna o meno.

Sto parlando della nostra implementazione di Python e di un caso d'uso simile che abbiamo riscontrato.

Abbiamo incontrato https://github.com/kvesteri/sqlalchemy-continuum che è un modo semplice per ottenere la tabella di controllo delle versioni per la tabella corrispondente. Numero minimo di righe di codice e cattura della cronologia per l'aggiunta, l'eliminazione e l'aggiornamento.

Questo serve più di una semplice is_deletedcolonna. Puoi sempre eseguire il backref della tabella delle versioni per verificare cosa è successo con questa voce. Indica se la voce è stata eliminata, aggiornata o aggiunta.

In questo modo non avevamo affatto bisogno di una is_deletedcolonna e la nostra funzione di cancellazione era piuttosto banale. In questo modo non dobbiamo nemmeno ricordarci di contrassegnare is_deleted=Falsein nessuna delle nostre API.

Soft Delete è una pratica di programmazione che viene seguita nella maggior parte delle applicazioni quando i dati sono più rilevanti. Si consideri un caso di applicazione finanziaria in cui una cancellazione per errore dell'utente finale può essere fatale. Questo è il caso in cui l'eliminazione temporanea diventa rilevante. Nella cancellazione temporanea l'utente non sta effettivamente cancellando i dati dal record, ma viene contrassegnato come IsDeleted su true (per convenzione normale).

In EF 6.x o EF 7 in poi Softdelete viene aggiunto come attributo, ma per il momento dobbiamo creare un attributo personalizzato.

Consiglio vivamente SoftDelete in un progetto di database ed è una buona convenzione per la pratica di programmazione.

La maggior parte delle volte viene utilizzato il softdeleting perché non si desidera esporre alcuni dati ma è necessario conservarli per motivi storici (un prodotto potrebbe essere interrotto, quindi non si desidera alcuna nuova transazione con esso ma è comunque necessario lavorarci la storia della transazione di vendita). A proposito, alcuni copiano il valore delle informazioni sul prodotto nei dati della transazione di vendita invece di fare un riferimento al prodotto per gestirlo.

In effetti sembra più una riformulazione di una funzione visibile / nascosta o attiva / inattiva. Perché questo è il significato di "eliminare" nel mondo degli affari. Vorrei dire che Terminator può eliminare le persone ma il capo le licenzia.

Questa pratica è un modello abbastanza comune e viene utilizzata da molte applicazioni per molte ragioni. Poiché non è l'unico modo per raggiungere questo obiettivo, migliaia di persone ti diranno che è fantastico o che è una stronzata ed entrambi hanno argomenti piuttosto buoni.

Da un punto di vista della sicurezza, SoftDelete non sostituirà il lavoro di Audit e non sostituirà anche il lavoro di backup. Se hai paura di "inserire / eliminare tra due casi di backup", dovresti leggere i modelli di ripristino completo o in blocco. Ammetto che SoftDelete potrebbe rendere il processo di ripristino più banale.

Sta a te conoscere la tua esigenza.

Per fornire un'alternativa, abbiamo utenti che utilizzano dispositivi remoti che si aggiornano tramite MobiLink. Se cancelliamo i record nel database del server, quei record non vengono mai contrassegnati come eliminati nei database del client.

Quindi facciamo entrambe le cose. Lavoriamo con i nostri clienti per determinare per quanto tempo desiderano essere in grado di recuperare i dati. Ad esempio, in genere i clienti ei prodotti sono attivi fino a quando il nostro cliente non dice che dovrebbero essere eliminati, ma la cronologia delle vendite viene conservata solo per 13 mesi e quindi viene eliminata automaticamente. Il cliente potrebbe voler mantenere i clienti e i prodotti eliminati per due mesi ma conservare la cronologia per sei mesi.

Quindi eseguiamo uno script durante la notte che contrassegna le cose logicamente cancellate in base a questi parametri e poi due / sei mesi dopo, tutto ciò che è marcato logicamente cancellato oggi sarà cancellato definitivamente.

Ci interessa meno la sicurezza dei dati che avere enormi database su un dispositivo client con memoria limitata, come uno smartphone. Un cliente che ordina 200 prodotti due volte a settimana per quattro anni avrà oltre 81.000 righe di storia, di cui il 75% al ​​cliente non interessa se vede.

Tutto dipende dal caso d'uso del sistema e dai suoi dati.

Ad esempio, se stai parlando di un sistema regolamentato dal governo (ad esempio un sistema presso un'azienda farmaceutica che è considerato una parte del sistema di qualità e deve seguire le linee guida della FDA per i record elettronici), allora è dannatamente meglio non fare eliminazioni forzate! Un revisore della FDA può entrare e chiedere tutte le registrazioni nel sistema relative al numero di prodotto ABC-123 e tutti i dati dovrebbero essere disponibili. Se il proprietario del processo aziendale afferma che il sistema non dovrebbe consentire a nessuno di utilizzare il numero di prodotto ABC-123 su nuovi record in futuro, utilizza invece il metodo di eliminazione temporanea per renderlo "inattivo" all'interno del sistema, pur conservando i dati storici.

Tuttavia, forse il tuo sistema ei suoi dati hanno un caso d'uso come "monitoraggio del tempo al Polo Nord". Forse prendi le letture della temperatura una volta ogni ora e alla fine della giornata aggrega una media giornaliera. Forse i dati orari non verranno più utilizzati dopo l'aggregazione e dovresti eliminare definitivamente le letture orarie dopo aver creato l'aggregazione. (Questo è un esempio inventato e banale.)

Il punto è che tutto dipende dal caso d'uso del sistema e dei suoi dati, e non da una decisione da prendere puramente da un punto di vista tecnologico.

Bene! Come tutti hanno detto, dipende dalla situazione.

Se hai un indice su una colonna come UserName o EmailID e non ti aspetti mai che lo stesso UserName o EmailID venga utilizzato di nuovo; puoi procedere con un'eliminazione graduale.

Detto questo, controlla sempre se l'operazione SELECT utilizza la chiave primaria. Se l'istruzione SELECT utilizza una chiave primaria, l'aggiunta di un flag con la clausola WHERE non farebbe molta differenza. Facciamo un esempio (Pseudo):

Utenti tabella (UserID [chiave primaria], EmailID, IsDeleted)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

Questa query non farà alcuna differenza in termini di prestazioni poiché la colonna UserID ha una chiave primaria. Inizialmente, eseguirà la scansione della tabella in base a PK e quindi eseguirà la condizione successiva.

Casi in cui le eliminazioni soft non possono funzionare affatto:

La registrazione in quasi tutti i siti Web accetta EmailID come identificazione univoca. Sappiamo molto bene, una volta che un EmailID viene utilizzato su un sito web come Facebook, G +, non può essere utilizzato da nessun altro.

Arriva un giorno in cui l'utente desidera eliminare il proprio profilo dal sito web. Ora, se effettui una cancellazione logica, quell'utente non potrà mai più registrarsi. Inoltre, registrarsi di nuovo utilizzando lo stesso EmailID non significherebbe ripristinare l'intera cronologia. Lo sanno tutti, la cancellazione significa la cancellazione. In tali scenari, dobbiamo effettuare un'eliminazione fisica. Ma per mantenere l'intera cronologia dell'account, dovremmo sempre archiviare tali record in tabelle di archivio o tabelle eliminate.

Sì, in situazioni in cui abbiamo molti tavoli stranieri, la gestione è piuttosto complicata.

Inoltre, tieni presente che le eliminazioni soft / logiche aumenteranno la dimensione della tabella, quindi la dimensione dell'indice.

Ho già risposto in un altro post . Tuttavia, penso che la mia risposta sia più adatta alla domanda qui.

La mia soluzione pratica per soft-delete archivia con la creazione di una nuova tabella con i seguenti colonne: original_id, table_name, payload, (e una chiave primaria `id opzionale).

Dove original_idè l'ID originale del record eliminato, table_name è il nome della tabella del record eliminato ( "user"nel tuo caso), payloadè una stringa con stringa JSON da tutte le colonne del record eliminato.

Suggerisco anche di creare un indice sulla colonna original_idper il recupero dei dati di quest'ultimo.

Con questo modo di archiviare i dati. Avrai questi vantaggi

• Tieni traccia di tutti i dati nella cronologia
• Disporre di una sola posizione in cui archiviare i record di qualsiasi tabella, indipendentemente dalla struttura della tabella del record eliminato
• Nessuna preoccupazione per l'indice univoco nella tabella originale
• Nessuna preoccupazione di controllare l'indice esterno nella tabella originale
• Niente più WHEREclausole in ogni query per controllare l'eliminazione

C'è già una discussione qui che spiega perché la cancellazione graduale non è una buona idea nella pratica. L'eliminazione temporanea introduce alcuni potenziali problemi in futuro come il conteggio dei record, ...

I vantaggi sono la conservazione / perpetuazione dei dati. Un annullamento sarebbe una diminuzione delle prestazioni durante l'interrogazione o il recupero di dati da tabelle con una quantità significativa di eliminazioni soft. Nel nostro caso usiamo una combinazione di entrambi: come altri hanno menzionato nelle risposte precedenti, soft-delete users/clients/customersad esempio noi , e hard-deletesu items/products/merchandisetabelle in cui sono presenti record duplicati che non devono essere conservati.

Dipende dal caso, considera quanto segue:

Di solito, non è necessario "eliminare temporaneamente" un record. Mantenerlo semplice e veloce. es. eliminazione di un prodotto non più disponibile, quindi non devi controllare che il prodotto non sia stato eliminato temporaneamente in tutta l'app (conteggio, elenco prodotti, prodotti consigliati, ecc.).

Tuttavia, potresti prendere in considerazione la "cancellazione temporanea" in un modello di data warehouse. ad esempio, stai visualizzando una vecchia ricevuta su un prodotto eliminato. *