Base de données : Supprimer ou ne pas supprimer des enregistrements

Question

Je ne pense pas être la seule personne à s'interroger sur ce point. Que pratiquez-vous habituellement en matière de comportement des bases de données ? Préférez-vous supprimer physiquement un enregistrement de la base de données ? Ou est-il préférable de simplement marquer l'enregistrement avec un indicateur "supprimé" ou une colonne booléenne pour indiquer que l'enregistrement est actif ou inactif ?

Answer 1

Cela dépend certainement du contenu réel de votre base de données. Si vous l'utilisez pour stocker des informations de session, alors effacez-la immédiatement lorsque la session expire (ou est fermée), vous ne voulez pas que ces déchets traînent. Vous ne voulez pas que ces déchets traînent, car ils ne peuvent pas vraiment être réutilisés à des fins pratiques.

En gros, ce que vous devez vous demander, c'est si je dois restaurer cette information. Tout comme les questions supprimées sur SO, elles devraient simplement être marquées "supprimées", car nous autorisons activement l'annulation de la suppression. Nous avons également la possibilité de l'afficher pour certains utilisateurs, sans trop de travail supplémentaire.

Si vous ne cherchez pas activement à restaurer complètement les données, mais que vous souhaitez tout de même les conserver à des fins de surveillance (ou autres). Je vous suggère de trouver (dans la mesure du possible bien sûr) un schéma d'agrégation, et de le transférer dans une autre table. Ainsi, votre table primaire ne contiendra pas de données "supprimées" et votre table secondaire restera optimisée à des fins de contrôle (ou ce que vous aviez en tête).

Pour les données temporelles, voir : http://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/

Answer 2

Les avantages de l'utilisation d'un drapeau de suppression :

1. Vous pourrez récupérer les données plus tard si vous en avez besoin,
2. L'opération de suppression (mise à jour de l'indicateur) est probablement plus rapide que la suppression proprement dite.

Inconvénients de l'utilisation d'un drapeau de suppression :

1. Il est très facile de manquer AND DeletedFlag = 'N' quelque part dans votre SQL
2. La base de données est plus lente à trouver les lignes qui vous intéressent parmi toutes les autres.
3. En fin de compte, vous voudrez probablement le supprimer réellement de toute façon (en supposant que votre système soit performant. Qu'en sera-t-il lorsque cet enregistrement aura 10 ans et qu'il aura été "supprimé" 4 minutes après sa création ?)
4. Cela peut rendre impossible l'utilisation d'une clé naturelle. Vous pouvez avoir une ou plusieurs lignes supprimées avec la clé naturelle et une ligne réelle voulant utiliser cette même clé naturelle.
5. Il peut y avoir des raisons légales/de conformité pour lesquelles vous êtes censé supprimer réellement les données.

Answer 3

En complément de tous les postes...

Cependant, si vous prévoyez de marquer l'enregistrement, il est bon d'envisager de créer une vue, pour les enregistrements actifs. Cela vous évitera d'écrire ou d'oublier le drapeau dans votre requête SQL. Vous pouvez également envisager de créer une vue pour les enregistrements non actifs, si vous pensez que cela peut également être utile.

Answer 4

Je suis heureux d'avoir trouvé ce fil de discussion. Je me demandais moi aussi ce que les gens pensaient de cette question. J'ai mis en œuvre la fonction "marquer comme supprimé" pendant environ 15 ans sur de nombreux systèmes. Lorsqu'un utilisateur appelait pour dire que quelque chose avait été accidentellement supprimé, il était certainement beaucoup plus facile de le marquer comme non supprimé que de le recréer ou de le restaurer à partir d'une sauvegarde.

Nous utilisons postgresql et Ruby on rails. Il semble que nous puissions faire cela de deux façons : modifier rails ou ajouter un déclencheur ondelete et utiliser une fonction pl/pgsql pour marquer comme supprimé. Je penche pour cette dernière solution.

En ce qui concerne les performances, il sera intéressant de voir les résultats d'EXPLAIN-ANALYZE sur de grandes tables avec peu d'éléments supprimés ainsi que de nombreux éléments supprimés.

Dans les systèmes utilisés au fil du temps, j'ai constaté que les nouveaux utilisateurs ont tendance à faire des choses stupides, comme supprimer des choses par accident. Ainsi, lorsqu'une personne est nouvellement nommée à un poste, elle dispose de tous les droits d'accès de la personne qui occupait précédemment ce poste, mais sans aucune expérience. En supprimant accidentellement quelque chose et en étant capable de le récupérer rapidement, tout le monde peut se remettre au travail rapidement.

Mais comme quelqu'un l'a dit, il peut arriver que vous ayez besoin de récupérer cette clé particulière pour une raison ou une autre. Dans ce cas, vous devez vraiment la supprimer, puis recréer les enregistrements (ou la supprimer et modifier l'enregistrement).

Answer 5

Il existe également des problèmes juridiques dans les deux cas si des données personnelles sont impliquées. Je pense que cela dépend grandement de l'endroit où vous vous trouvez (ou de l'endroit où se trouve la base de données), et des conditions d'utilisation.

Dans certains cas, les personnes peuvent demander à être supprimées de votre système, auquel cas il faut procéder à une suppression définitive (ou au moins effacer toutes les informations personnelles).

Je vérifierais avec votre service juridique avant d'adopter une stratégie, quelle qu'elle soit, si des informations personnelles sont en jeu.