web-dev-qa-db-fra.com

Est-ce que soft supprime une bonne idée?

Est-ce que soft supprime une bonne idée ou une mauvaise idée?

Au lieu de supprimer réellement un enregistrement de votre base de données, vous devez simplement l'indiquer comme IsDeleted = true, Et lors de la récupération de l'enregistrement, vous pouvez l'indiquer comme False.

Est-ce une bonne idée?

Est-ce une meilleure idée de supprimer physiquement l'enregistrement, puis de le déplacer vers une base de données d'archives, et si l'utilisateur souhaite récupérer l'enregistrement, le logiciel le recherchera dans l'archive et le recréera?

136
001

Je dis que c'est une mauvaise idée, en général (avec quelques exceptions peut-être).

Tout d'abord, votre base de données doit être sauvegardée régulièrement. Par conséquent, vous ne devriez jamais vous retrouver dans une situation où vous perdriez des données de manière permanente à cause d'un DELETE (à moins qu'il ne s'agisse d'une suppression de données nouvellement ajoutées, bien sûr).

Deuxièmement, une suppression logicielle comme celle-ci signifie que vous devez maintenant inclure un WHERE IsDeleted = false clause dans chaque requête de cette table (et tant pis si vous vous associez à ces tables). Une erreur ici serait détectée dès qu'un utilisateur ou un testeur a remarqué qu'un enregistrement supprimé réapparaissait, ce qui pourrait prendre un certain temps. De plus, il serait facile pour un développeur d’omettre la clause WHERE des requêtes COUNT (*), ce qui pourrait prendre encore plus de temps à découvrir (j’ai travaillé sur un projet où cela se passait depuis des années; peu d’enregistrements ont été "effacés" , donc les totaux étaient proches de ce à quoi on s’attendait et personne ne l’a remarqué).

Enfin, une suppression logicielle fonctionnera sur une table avec des clés artificielles, mais ne fonctionnera potentiellement pas sur une table avec une clé primaire naturelle (par exemple, vous "supprimez" une personne d'une table à clé avec un numéro de sécurité sociale - que faites-vous lorsque vous S'il vous plaît ne dites pas "inclure IsDeleted dans une clé primaire composée".).

Dans une revue de conception, je m'attendrais à ce que le développeur démontre une connaissance des coûts et des avantages et présente une excellente raison d'effectuer les suppressions progressives de cette manière. "Pourquoi pas le faire?" n'est pas une excellente raison.

100
MusiGenesis

Ce n'est jamais une mauvaise idée d'éviter une perte de données potentielle.

J'ai toujours soft-delete. Dans les cas où la ou les bases de données doivent être nettoyées d'un ou de plusieurs enregistrements, j'utilise généralement un processus en deux étapes de suppression progressive puis de vidage d'une "corbeille" d'enregistrements, ou une approche de type gestion de document permettant aux enregistrements de documenter. être éloigné, puis passer par un processus d'approbation avant suppression définitive.

93
Robert Harvey

Cela dépend des circonstances. Je pourrais voir des situations où vous êtes légalement obligé de vraiment supprimer quelque chose. Peut-être que quelqu'un a demandé que son numéro de sécurité sociale soit définitivement supprimé de votre système. Ou peut-être avez-vous un enregistrement en double que vous souhaitez consolider en un seul enregistrement. Garder le doublon traîner avec un drapeau supprimé pourrait ne pas être avantageux.

Il existe également un inconvénient technique: vous ne pouvez pas effectuer de suppressions en cascade, ce qui efface automatiquement toute référence aux données supprimées pour empêcher les violations de clé étrangère. Ce n'est pas nécessairement un gros problème, mais c'est quelque chose à garder à l'esprit.

Sinon, je pense que c'est une bonne idée.

32
devuxer

Si vous envisagez d'utiliser la suppression logicielle, c'est une bonne idée d'avoir un champ delete_date au lieu d'un champ is_deleted. Vous obtenez une bonne donnée supplémentaire au lieu du champ de bits.

24
Josh Smeaton

L’un des problèmes majeurs de la suppression logicielle réside dans le fait que des données indésirables peuvent potentiellement affecter les performances de la base de données. Il y a plusieurs années, l'un de mes clients m'a demandé d'effectuer une suppression logicielle de tous les éléments de base de données. Ma solution consiste à déplacer tous les éléments "supprimés" vers une table de sauvegarde au lieu de les laisser aux tables en cours d'exécution.

20
xandy

C'est une bonne idée de savoir quand et si une suppression invalide est absolument catastrophique et que la récupération doit être simple. C'est aussi une bonne idée si vous voulez garder une trace de tout ce qui a été et que "supprimer" signifie vraiment seulement "masquer". Sens, c'est à la situation.

17
Anthony Pegram

Je n'essaierai pas d'être "politiquement correct à ce sujet". Si vous préconisez la suppression progressive, vous devez passer par un examen du cerveau.

1) Tout d’abord, que faites-vous exactement en ne supprimant pas les lignes du tableau? Juste le fait qu'à l'avenir, vous pourrez accéder à ces lignes, n'est-ce pas? Alors pourquoi ne pas simplement créer une table d’archive et y déplacer les lignes? Quel est le problème avec ça?

2) Avec la suppression logicielle, vous créez une requête inutile sur is_active ou une requête sur une colonne d'horodatage. Ce n'est que gaspillage lorsque vous écrivez des requêtes plus simples. Oui, cela fonctionnera avec une vue, mais les vues ne sont-elles pas un appendice supplémentaire? Chaque vue est un SQL supplémentaire, un coût de performance supplémentaire, inférieur à tout SGBDR commercial, tout n’est qu’une table. Il n’ya rien de magique dans les vues si ce n’est le fait que vous ne savez pas écrire des requêtes au-dessus des tables.

3) Oui, cela fonctionnera avec une vue ou un MV. Mais ensuite, j'ai vu des requêtes en production avec FTS et tout fonctionne toujours! Les merveilles d'un matériel moderne et d'un logiciel solide. Mais cela ne règle pas le problème non plus. Donc, selon la même logique, ce n'est pas parce que cela fonctionne que c'est À DROITE

4) La complexité de la suppression logicielle ne s'arrête jamais à une simple sélection.

A) Supposons que vous ayez une contrainte UNIQUE. Maintenant, vous supprimez une ligne en douceur mais la colonne avec la contrainte UNIQUE est toujours là. Lorsque vous souhaitez rajouter les mêmes données, vous ne pouvez pas le faire sans "astuces" supplémentaires.

B) Vous pouvez avoir des associations allant du tableau A au tableau B et lorsque vous supprimez en douceur un élément du tableau A, vous devez vous assurer que des requêtes indépendantes sur le tableau B prennent en compte ce fait. Supposons qu'une page de détail typique travaille sur un detail_id.

Maintenant, un master_id est supprimé de manière souple, mais vous avez toujours des liens permanents avec detail_id de ce master_id partout. Lorsque vous effectuez une suppression difficile sur master_id, ces détails n'existent tout simplement pas. Maintenant, avec soft delete, ils existent toujours et ils doivent être conscients du fait que leur master_id est en mode soft-delete.

cela ne s'arrêtera pas à une simple table_A.is_active = 0 ou 1 étape.

5) Faire des suppressions difficiles est simple et correct.

R) Personne n’a rien à ajouter ni à s’inquiéter de quoi que ce soit ailleurs.

  1. La logique de votre application est plus simple
  2. Votre base de données est plus petite
  3. Vos requêtes sont plus rapides

Il suffit d'archiver les données + les pièces liées et vous devriez être bon.

9
rjha94

Les suppressions progressives vous permettraient également de révoquerDELETE privilèges à partir du compte de base de données utilisé par l'application.

8
Daniel Vassallo

Parfois, des suppressions douces sont nécessaires. Par exemple, supposons que vous ayez une table Invoice qui référence une table Products. Une fois que vous avez créé une facture avec un produit spécifique, vous ne pouvez jamais supprimer ce produit (et si votre RI est configuré correctement, il ne vous le laissera pas).

Ce scénario spécifique suppose que vous ne souhaiterez jamais supprimer les factures qui, dans une entreprise réelle, ne voudraient probablement pas supprimer les données financières historiques.

Bien qu'il existe de nombreux autres cas où vous ne seriez pas en mesure de supprimer certaines données en tant qu'effet secondaire d'une dépendance en amont de la chaîne n'étant pas supprimable pour des raisons professionnelles ou autres.

5
joshperry

sous Oracle, si vous ajoutez la clé primaire à la table recycle_bin que vous créez, puis ajoutez une stratégie de sécurité au niveau de la ligne, vous pouvez supprimer les valeurs de toutes les requêtes lorsque la ligne se trouve dans la corbeille, la suppression du pk de la corbeille restaurer automatiquement toutes les données. pas besoin de changer vos autres requêtes pour accommoder la logique.

4
Randy

Cela dépend des données. Certaines données ne peuvent pas être supprimées en raison d'exigences légales/d'audit.

Les sites de réseaux sociaux, d’autre part devraient offrent la possibilité de supprimer un compte avec toutes les données associées, y compris les informations de contact, des photos, des messages, etc. Facebook.

4
armandino

Cela a toutefois un coût, car vous devez mettre à jour vos requêtes et vos index pour pouvoir exclure les lignes supprimées.

Peut-être qu'au lieu de changer de drapeau, déplacez-le vers une autre table "Corbeille".

En outre, on pourrait dire que ce n'est qu'une solution partielle, car elle ne couvre que les suppressions, mais lorsque vous mettez à jour une ligne, vous écrasez toujours l'ancienne valeur.

En général, je dirais de ne jamais rien supprimer sauf si vous devez le faire. L'espace disque est bon marché ces jours-ci. Bien sûr, il y a des limites, il y a des données que vous êtes légalement tenu d'effacer, il y a des données qui ne sont vraiment pas si importantes, et peut-être n'avez-vous pas besoin de garder les anciennes données en ligne et dans le même tableau (une archive quelque part) fonctionnerait aussi).

3
Thilo

Juste pour ajouter un centime. Je toujours soft-delete; bien que cela coûte la performance, mais très légèrement. Pensez au coût lorsque votre client se plaint de l’arrêt de votre logiciel après avoir effectué certaines opérations dont elle ne se souvient même pas. Eh bien, c’est peut-être un bon exemple, mais vous ne sauriez jamais ce qui ne va pas, qui a fait quoi, ce qui était avant et ce qui a été inséré après. Dans ce cas, cela serait pratique. Cette fonctionnalité est très utile à des fins d’audit et de nombreux clients demandent à ce que des rapports d’audit de ce type soient fournis.

En outre, dans la plupart des applications basées sur un flux de travail, il s’agit d’une fonction logicielle/exigence selon laquelle le client est intéressé par les "actions" effectuées sur un élément de travail; quelles valeurs ont été assignées et qui les a traitées, etc.

1
KMån

Je suis fan de soft-deletes. Principalement pour empêcher les suppressions en cascade. Toutefois, il faut du code supplémentaire pour que, si vous sélectionnez un objet enfant, il se joigne aux objets parent (et à tous les parents!) Pour vous assurer qu'aucun d'entre eux n'est supprimé. Vous pouvez également utiliser la suppression logicielle en cascade, mais si vous souhaitez les restaurer ultérieurement, vous risquez de ne pas savoir quels enfants ont déjà été supprimés et quels enfants ont été supprimés en raison de la cascade.

De plus, je garde une date-heure de révision et un nom d'utilisateur de révision sur chaque objet, afin de savoir qui l'a modifié (ou supprimé de manière logicielle) en dernier. Ensuite, pour une piste d'audit, je crée une table * History (comme CustomerHistory) qui est insérée après chaque UPDATE dans la table d'origine. Ainsi, après la modification ou la suppression logicielle d’un objet, j’ai un enregistrement des auteurs de l’action et du dernier état connu de l’objet.

0
Brad Nabholz

J'ai rencontré soft-supprime pour les scénarios généraux suivants:

CAS 1: supprimer l'enregistrement d'utilisateur/code visible, mais le placer au niveau de la base de données, car l'entreprise est intéressée par le fait de savoir qu'elle en a un.
Ces exigences sont principalement dictées par les activités. Généralement, la base est une obligation légale (comme les scénarios @joshperry & @armandino) d’avoir l’ancien enregistrement dans la base de données et de créer un nouvel enregistrement pour chaque modification apportée. À ce stade, je regarderais le cas 2 et évaluerais s'il répond aux exigences avant d’avoir un drapeau IsDeleted

CAS 2: des traces d'audit pour suivre l'évolution d'un enregistrement - il existe une multitude d'articles décents en ligne permettant de conserver des traces d'audit dans une base de données.

HTH.

0
Sunny