Discussion :

[Kropernic]

Hello,

Je me pose une question quant à "l'historisation" des données.

J'entends pas historisation, le fait de garder quelque part les lignes supprimées par un utilisateur pour le cas où il se serait trompé et qu'il faille les récupérer (sans devoir faire un restore de la DB )

Dans un précédent projet, j'avais créé un schéma Deleted et ce dernier abritait un clône de chaque table du schéma de prod (dbo en l'occurence). Ces clônes ayant été débarrassés de toutes contraintes bien sûr (sinon ça marche pas des masses...).
Au final, j'ai pu constaté que ce n'était pas des plus pratiques car à chaque modification du schéma de prod (même mineure), il fallait alors la reporter sur le schéma d'archivage ainsi que modifié le trigger AFTER DELETE de la table de prod ayant subie les modifs. Assez lourd donc.

Pour un nouveau projet, j'envisage d'ajouter à chaque table (enfin celles pour lesquels cet archivage est nécessaire) deux colonnes. Une colonne DELETED_ON de type datetime2 et une colonne DELETED_BY de type varchar. Ces colonnes seraient alors mises à jour via un trigger INSTEAD OF DELETE. Pour compléter cela, une vue sur chaque table faisant le filtre des données supprimées et la boucle est bouclée.

Sur le papier, ça a l'air de tourner (tout autant que la première manière de faire en tout cas).

Je me demandais ce qu'en pense les pros. Comment faites-vous de votre côté ?

[Sankasssss]

Je suis très loin d'être pro dans le sujet mais nous utilisons des colonnes pour marquer le delete.
C'est effectivement moins lourd à coder et en plus c'est plus facile si tu veux les afficher par après, une simple modification de la requête affiche l'historique dans la même table.

Mais ça pose des soucis pour l'historisation avec les clés primaires quand tu dois garder la même clé, la où ton ancien modèle aurait fonctionné avec un trigger AFTER UPDATE.

Je suis aussi intéressé par d'autres avis plus expérimenté sur la question.

[Kropernic]

Mais ça pose des soucis pour l'historisation avec les clés primaires quand tu dois garder la même clé, la où ton ancien modèle aurait fonctionné avec un trigger AFTER UPDATE.

Comment ça ? Qu'utilises-tu comme clefs primaires ? Perso, je ne vois pas le moindre souci... Eventuellement au niveau d'une contrainte d'unicité (clef alternative) mais le problème se résout en y ajoutant la colonne contenant la date (et l'heure) à laquelle la ligne a été "effacée".

[Sankasssss]

Si ta clé n'est pas auto-incrémentée, tu dois effectivement y ajouter la date d'effacement ce que je ne trouve pas "propre" comme clé.

[Zabriskir]

Si pas beaucoup de suppressions dans votre table, je trouve bof de créer 2 colonnes qui seront à NULL pour la majorité des lignes.
Dans ce cas, je préfère créer une table à part pour stocker les suppressions dans laquelle on retrouve 3 colonnes : la clé primaire de la ligne supprimée, la date et l'utilisateur.
Ensuite, pour filtrer les lignes supprimées dans votre table, jointure externe ou sous-requête NOT EXISTS avec cette table des suppressions.

@+

[darkelend]

En tout cas, pour la deuxième solution, c'est un bon exemple d'utilisation des indexs filtrés

[Kropernic]

Si ta clé n'est pas auto-incrémentée, tu dois effectivement y ajouter la date d'effacement ce que je ne trouve pas "propre" comme clé.

Ah ouais, les héritages et les tables de jointure... Je les avais oubliées celles-là. Donc ouais, faut alors ajouter la date d'effacement à la clef et c'est vrai que j'trouve ça pas top non plus... Surtout qu'une colonne de clef ne peut pas être marquée à NULL

[Kropernic]

En tout cas, pour la deuxième solution, c'est un bon exemple d'utilisation des indexs filtrés

Certes, mais tu utiliserais quelle méthode si tu étais à ma place ?
Première, seconde, autre ? Si autre, laquelle ?

[darkelend]

Certes, mais tu utiliserais quelle méthode si tu étais à ma place ?
Première, seconde, autre ? Si autre, laquelle ?

Tout dépend du besoin. Si le besoin est d'historiser toutes les actions car c'est intéressant fonctionnelement, je modifierais le modèle pour conserver l'historique. Un versionning de la ligne avec la date et l'action.

Si c'est juste pour conserver les données au cas ou l'utilisateur s'est trompé, je mettrais une fenetre de confirmation avant de supprimer + backup/restore.

Sinon tu peux aussi mettre en place le CDC.

[Kropernic]

Tout dépend du besoin. Si le besoin est d'historiser toutes les actions car c'est intéressant fonctionnelement, je modifierais le modèle pour conserver l'historique. Un versionning de la ligne avec la date et l'action.

Si c'est juste pour conserver les données au cas ou l'utilisateur s'est trompé, je mettrais une fenetre de confirmation avant de supprimer + backup/restore.

Sinon tu peux aussi mettre en place le CDC.

Le CDC, c'est bien mais c'est uniquement version Entreprise... J'ai beau être fan des capitaines Kirk et Picard, ça ne suffit pas pour Microsoft .

En ce qui me concerne, je suis bien dans le 2e besoin que tu cites.
Tu ne toucherais donc à rien et te contenterais des backup/restore pour récupérer au besoin. C'est vrai que, en général, j'ai tendance à envoyer l'utilisateur bouler (c'est français cette expression?) en lui disant qu'il n'avait qu'à faire attention quand il a reçu la demande de confirmation. (y en qui arrive à se gourer même pas 2 demandes de confirmation...)

J'aime bien ta solution... Ca fait moins de travail pour moi ^^