Voglio essere chiaro quando discuto un'implementazione che stiamo usando soft-delete (non rimuovendo immediatamente i dati dal database). Come posso chiamare il nostro approccio? Il meglio che ho è "CRUD con soft delete", solo "CRU", o CRUH (crea, leggi, aggiorna, nascondi), che afaik è un neologismo.
Lo chiami "CRUD."
La designazione di un'app come app CRUD ha lo scopo di indicare che molte delle sue funzioni centrali si concentrano attorno alle comuni attività di gestione dei record: creare, leggere, aggiornare ed eliminare. "CRUD", tuttavia, non ha lo scopo di descrivere completamente l'app.
Le app CRUD hanno una gamma di attività, variazioni e implementazioni. Alcuni soft-delete, alcuni difficili. Scrivono in vario modo i dati su JSON, YAML, CSV e 1.000 altri formati di file; altri scrivono su database backend. Sono scritti in diverse lingue. Alcune sono app terminali, altre sono grafiche o interfaccia web. Alcuni aggiungono ricerca, sfoglia, segnala, elimina e altre funzionalità.
Se inizi a provare a codificare tutte queste scelte nell'acronimo, perdi di vista la comunanza. Invece di identificarti con un flusso di lavoro comune, stai descrivendo tutti i modi in cui l'app varia da scelte comuni e ti ritroverai con orribili acronimi di suoni e furia come CRUSHJW che nessuno, a parte te capirai. Perché devi solo segnalare hide-not-delete, yes-it-has-search, it-writes-to-JSON e web-front-end. Ma aspetta! È scritto in Python, ha funzionalità di reporting e correzione degli errori significative. Devo menzionarli, quindi: CRUSHJWERP! Molto meglio!
No, non proprio. L'acronimo CRUD ha lo scopo di identificare un'app come appartenente a un'ampia famiglia di app di gestione dei record che la maggior parte degli sviluppatori riconosce e capisce all'istante. Non è pensato per codificare tutte le sue varianti ed estensioni. In aggiunta all'esempio fantasioso dei binari di cui sopra, l'importanza della semplicità e della comunanza è dimostrata dal fatto storico che anche funzioni addizionali estremamente comuni (ad esempio ricerca) non l'hanno resa nell'acronimo comune.
Elimina è Elimina. Se stai nascondendo i dati dietro un flag, o rimuovendoli dal tuo DB, o scrivendo un archivio su un'altra tabella, o generando una voce di controllo dello stile del log delle transazioni, o cancellando i bit dal disco un migliaio di volte usando valori crittografati casualmente. .. non importa. Hai ancora cancellato i dati dalla vista dell'utente. Per quanto riguarda un processo di business, i dati sono spariti anche se ne hai ancora una copia in giro.
Considerare l'alternativa se non si pensa all'eliminazione avviata dall'utente iniziale come eliminazione:
così quando l'utente fa clic su elimina, è cancellato giusto?
No, impostiamo un flag solo per nasconderlo dalla visualizzazione finché il processo di eliminazione non viene eseguito ogni 30 giorni.
Quindi è cancellato?
No, quindi è stato spostato in un percorso di archiviazione per i 7 anni regolamentari.
Quindi viene eliminato?
No, quindi finisce sui dischi di backup che vengono inviati alla funzione di archiviazione.
Ma poi viene cancellato, sicuramente?
Ehm, beh, immagino di sì, ma nessuno ha lavorato qui abbastanza a lungo da scoprirlo.
"Mai" implica un molto molto tempo.
Hai permesso di mantenere i dati così a lungo?
Quali sono le tue politiche di conservazione dei dati?
Conservate informazioni personali identificabili (PII), che devono essere tenute aggiornate; tenerlo indefinitamente (e non mantenerlo) potrebbe portarti in ogni sorta di difficoltà [legali].
E poi, naturalmente, c'è il costo di mantenere tutte queste "cose" per sempre:
Chi ha intenzione di pagare per tutto questo?
Leggi altre domande sui tag terminology crud