Tu as plusieurs raisons utiles a la conservation de l'historique: audit, debug, analyses statistiques. Le premier de la dépêche l'explique bien. En particulier, j'ai bossé sur une application ou tout (ou presque) devait être audité: chaque objet métier avait un "statut" qui était la machine a état du pauvre. Et bien c'est super utile pour retracer l'historique de ton objet métier (audit) voire comprendre comment ton objet est arrivé dans l'état actuel (a quelle date, a recouper avec les logs). C'est une min d'or d'informations. D'ailleurs, on ne faisait pas un "delete" sur les objets en base de donnée: on les marquait comme inactifs, complétés, annulés, etc. (en plus, ça améliorait les perfs en évitant un table lock)
[^] # Re: Historique
Posté par djano . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 2.
Tu as plusieurs raisons utiles a la conservation de l'historique: audit, debug, analyses statistiques. Le premier de la dépêche l'explique bien. En particulier, j'ai bossé sur une application ou tout (ou presque) devait être audité: chaque objet métier avait un "statut" qui était la machine a état du pauvre. Et bien c'est super utile pour retracer l'historique de ton objet métier (audit) voire comprendre comment ton objet est arrivé dans l'état actuel (a quelle date, a recouper avec les logs). C'est une min d'or d'informations. D'ailleurs, on ne faisait pas un "delete" sur les objets en base de donnée: on les marquait comme inactifs, complétés, annulés, etc. (en plus, ça améliorait les perfs en évitant un table lock)