Le client veut que certaines données apparaissent après que vous ayez supprimé des lignes. Géant du système / pas ma création. Approche rapide mais sûre ? Nom / classe du problème de conception ?

Question

C'est un problème assez courant, il a probablement un nom, mais je ne sais pas lequel.

A.) L'utilisateur voit une information obscure dans la rangée B de L_OBSCURE_INFO affichée sur un écran à un moment donné. Elle se trouve dans la table L_Obscure_info.

B.) Dans certaines circonstances, nous voulons supprimer correctement les données dans L_OBSCURE_INFO. Malheureusement, personne n'a tenu compte du fait que l'utilisateur pourrait vouloir revenir en arrière et voir un élément d'information aléatoire qui se trouvait tout récemment dans L_OBSCURE_INFO.

C.) Le système est énorme et L_OBSCURE_INFO est utilisé en permanence. Vous n'avez aucune idée des ramifications de l'implémentation d'une sorte de hack et, quoi que vous fassiez, vous ne voulez pas introduire plus de bogues.

Je pense que la meilleure approche serait de créer une table L_OBSCURE_INFO_HISTORY et d'y enregistrer un enregistrement à chaque fois que vous modifiez des données. Mais que Dieu vous aide à garantir l'exactitude des données dans ce système où L_OBSCURE_INFO est utilisé partout et où vous n'avez pas le temps d'implémenter L_OBSCURE_INFO_HISTORY.

Existe-t-il une solution de conception particulièrement facile et intelligente pour ce type de problème - en gros, un hack de base de données élégant ? Si ce n'est pas le cas, ce type de problème de conception relève-t-il d'une classe particulière de problèmes ou a-t-il un nom ?

Answer 1

Utilisez un déclencheur de table de base de données pour conserver votre historique dans une deuxième table.

Answer 2

Si la consultation de l'historique des suppressions (et je suppose des mises à jour) est une exigence, la table d'historique que vous avez décrite est probablement votre meilleure option.

Si, comme vous le dites, la table est "touchée partout" et que vous ne pouvez pas contrôler l'écriture de l'historique via le code de l'application, vous devrez mettre en œuvre un déclencheur de base de données qui prend essentiellement un instantané de la ligne à chaque fois qu'une modification est effectuée (ou seulement les suppressions, si c'est la limite de votre besoin).

Une autre option pourrait consister à ajouter une colonne "is_active" dans la table et, au lieu d'autoriser les suppressions, permettre aux utilisateurs d'inactiver des lignes. Il s'agit en fait d'une "suppression douce", ce qui n'est pas toujours une bonne pratique, car il est très difficile de filtrer les enregistrements inactifs dans chaque requête.

Si vous avez la possibilité de mettre en œuvre une solution dans le code de l'application (c'est-à-dire que personne ne touche aux données sauf par l'intermédiaire de l'application), vous pouvez mettre en œuvre un mécanisme de journalisation pour enregistrer l'état d'une ligne qui est sur le point d'être supprimée.