Implémentation de la suppression logicielle avec un impact minimal sur les performances et le code

Question

Il existe des similaires questions sur le sujet, mais elles ne m'aident pas vraiment.

Je souhaite implémenter une fonctionnalité de suppression logicielle comme sur StackOverflow, où les éléments ne sont pas vraiment supprimés, mais simplement masqués. J'utilise une base de données SQL. Voici 3 options:

• Ajoutez un champ booléen is_deleted.

  • Avantages: Simple.
  • Inconvénients: aucun enregistrement de date. M'oblige à ajouter un is_deleted = 0 dans chaque requête.

• Ajoutez un champ de date deleted_date. Ceci est défini sur NULL s'il n'est pas supprimé.

  • Avantages: a une date.
  • Inconvénients: encombrent toujours mes requêtes.

Pour les deux éléments ci-dessus

• Cela aura également un impact sur les performances car il y a toutes ces lignes inutiles. Ils doivent encore être conservés dans des index. De plus, un index sur la colonne deleted n'aidera pas lors de la récupération des lignes non supprimées (la majorité). Une analyse complète du tableau est nécessaire.

Une autre option consiste à créer un tableau séparé pour contenir les éléments supprimés:

• Avantages: performances améliorées lors de l'interrogation de lignes non supprimées. Pas besoin d'ajouter des conditions à mes requêtes sur les lignes non supprimées. Maintenance des index plus facile.
• Inconvénients: Complexité: nécessite la migration des données pour la suppression et la restauration. Besoin de nouvelles tables. L'intégrité référentielle est plus difficile à gérer.

Y a-t-il une meilleure option?

Answer 1

Si la clé est numérique, je gère une "suppression logicielle" en annulant la clé.(Bien sûr, ne fonctionnera pas pour les clés d'identité).Vous n'avez pas du tout besoin de modifier votre code et pouvez facilement restaurer l'enregistrement en multipliant par -1.

Juste une autre approche à laquelle réfléchir ... Si la clé est alphanumérique, vous pouvez faire quelque chose de similaire en ajoutant un caractère "marqueur" unique.Puisque les enregistrements supprimés commenceront tous par ce marqueur, ils finiront par eux-mêmes dans l'index.

Answer 2

Personnellement, je baserais ma réponse sur la fréquence à laquelle vous prévoyez que vos utilisateurs souhaitent accéder à ces données supprimées ou "restaurer" ces données supprimées.

Si c'est souvent, alors j'irais avec un champ "Date_Deleted" et mettre un "IsDeleted" calculé dans mon poco dans le code.

Si ce n'est jamais (ou presque jamais), alors une table d'historique ou une table supprimée est bonne pour les avantages que vous avez expliqués.

Personnellement, je n'utilise presque jamais de tables supprimées (et j'opte pour isDeleted ou date_deleted) en raison du risque potentiel pour l'intégrité référentielle.Vous avez A -> B et vous supprimez l'enregistrement de la base de données B ... Vous devez maintenant gérer l'intégrité référentielle en raison de votre choix de conception.

Answer 3

À mon avis, la meilleure façon d'avancer, lorsque l'on pense à la mise à l'échelle et aux éventuelles tailles de table / base de données est votre troisième option - une table séparée pour les éléments supprimés.Une telle table peut éventuellement être déplacée vers une autre base de données pour prendre en charge la mise à l'échelle.

Je pense que vous avez répertorié les trois options les plus courantes.Comme vous l'avez vu, chacun présente des avantages et des inconvénients.Personnellement, j'aime avoir une vision plus longue des choses.

Answer 4

Supposons que nous créons un champ appelé dead pour marquer les lignes supprimées.Nous pouvons créer un index où le champ dead est faux. De cette façon, nous recherchons uniquement les lignes non supprimées à l'aide de l'index d'utilisation de l'indice.

Answer 5

Je pense que votre analyse des options est bonne, mais vous avez manqué quelques points pertinents que j'énumère ci-dessous.Presque toutes les implémentations que j'ai vues utilisent une sorte de champ supprimé ou de contrôle de version sur la ligne, comme vous le suggérez dans vos deux premières options.

Utilisation d'un tableau avec l'indicateur supprimé: Si vos index contiennent tous le champ indicateur supprimé en premier et que votre requête contient principalement une structure de type where isdeleted= false, cela vous résout les problèmes de performances et les index excluent très efficacement les lignes supprimées.Une logique similaire pourrait être utilisée pour l'option de date de suppression.

Utilisation de deux tableaux En général, vous devez apporter des modifications massives aux rapports, car certains rapports peuvent faire référence à des données supprimées (comme les anciens chiffres de vente peuvent faire référence à une catégorie de ventes supprimée).On peut surmonter cela en créant une vue qui est une union des deux tables à lire et à écrire uniquement dans la table des enregistrements actifs.