In uno dei nostri database, abbiamo distinto tra transactional e dictionary record.
In un paio di parole, transactional i record sono cose che non puoi ripristinare nella vita reale, come una chiamata da un cliente. Puoi cambiare il nome del chiamante, lo stato, ecc., ma non puoi ignorare la chiamata stessa.
Dictionary i record sono cose che puoi modificare, come assegnare una city a un cliente.
Transactional record e cose che li portano non sono mai stati cancellati, mentre dictionary quelli potrebbero essere eliminati bene.
Con "cose che portano a loro" intendo che non appena il record appare nelle regole aziendali che possono portare a un transactional record, questo record diventa anche transactional .
Ad esempio, una city può essere cancellato dal database. Ma quando è apparsa una regola che diceva "invia un SMS a tutti i clienti di Mosca ", le città sono diventate transactional record, altrimenti non saremmo in grado di rispondere alla domanda "perché questo SMS fatti inviare".
Una regola pratica per distinguere era questa:sono solo affari della mia azienda?
Se uno dei miei dipendenti ha preso una decisione in base ai dati del database (ad esempio, ha redatto un rapporto in base al quale è stata presa una decisione di gestione e quindi il rapporto sui dati è stato basato sulla scomparsa), è stato considerato OK eliminare questi dati.
Ma se la decisione ha influenzato alcune azioni immediate con i clienti (come chiamare, pasticciare con l'equilibrio del cliente ecc.), tutto ciò che ha portato a queste decisioni è stato mantenuto per sempre.
Può variare da un modello di business all'altro:a volte può essere necessario registrare anche i dati interni, a volte va bene eliminare i dati che interessano il mondo esterno.
Ma per il nostro modello di business, la regola di cui sopra ha funzionato bene.
