Suppression physique ou logique / douce de l'enregistrement de la base de données?

Quel est l'avantage de faire une suppression logique / logicielle d'un enregistrement (c'est-à-dire définir un indicateur indiquant que l'enregistrement est supprimé) par rapport à la suppression réelle ou physique de l'enregistrement?

Est-ce une pratique courante?

Est-ce sécurisé?

Les avantages sont que vous conservez l'historique (bon pour l'audit) et que vous n'avez pas à vous soucier de la cascade d'une suppression à travers diverses autres tables de la base de données qui référencent la ligne que vous supprimez. L'inconvénient est que vous devez coder toutes les méthodes de rapport / d'affichage pour prendre en compte le drapeau.

Pour autant que ce soit une pratique courante - je dirais oui, mais comme pour tout ce que vous utilisez, cela dépend des besoins de votre entreprise.

EDIT: Pensée à une autre plage désavantageuse - Si vous avez des index uniques sur la table, les enregistrements supprimés occuperont toujours l'enregistrement "un", vous devez donc également coder autour de cette possibilité (par exemple, une table utilisateur qui a un index unique sur nom d'utilisateur; Un enregistrement supprimé bloquerait toujours le nom d'utilisateur des utilisateurs supprimés pour les nouveaux enregistrements. Pour contourner ce problème, vous pourriez ajouter un GUID à la colonne du nom d'utilisateur supprimé, mais c'est une solution de contournement très piratée que je ne recommanderais pas. Probablement dans ce cas mieux vaut simplement avoir une règle selon laquelle une fois qu'un nom d'utilisateur est utilisé, il ne peut jamais être remplacé.)

Les suppressions logiques sont-elles une pratique courante? Oui, j'ai vu cela dans de nombreux endroits. Sont-ils sécurisés? Cela dépend vraiment de la sécurité des données avant de les supprimer?

Quand j'étais Tech Lead, j'ai exigé que notre équipe conserve chaque élément de données, je savais à l'époque que nous utiliserions toutes ces données pour créer diverses applications BI, même si à l'époque nous ne savions pas quelles seraient les exigences. être. Bien que cela soit bon du point de vue de l'audit, du dépannage et des rapports (il s'agissait d'un site de commerce électronique / d'outils pour les transactions B2B, et si quelqu'un utilisait un outil, nous voulions l'enregistrer même si son compte était désactivé par la suite), il y avait plusieurs inconvénients.

Les inconvénients comprennent (sans compter les autres déjà mentionnés):

1. Implications sur les performances de conserver toutes ces données, Nous développons diverses stratégies d'archivage. Par exemple, un domaine de l'application était sur le point de générer environ 1 Go de données par semaine.
2. Le coût de conservation des données augmente avec le temps, alors que l'espace disque est bon marché, la quantité d'infrastructure pour conserver et gérer des terrabytes de données en ligne et hors ligne est considérable. Il faut beaucoup de disque pour la redondance, et le temps des gens pour s'assurer que les sauvegardes se déplacent rapidement, etc.

Au moment de décider d'utiliser des suppressions logiques, physiques ou l'archivage, je me posais les questions suivantes:

1. Ces données doivent-elles être réinsérées dans le tableau. Par exemple, les comptes d'utilisateurs correspondent à cette catégorie car vous pouvez activer ou désactiver un compte d'utilisateur. Si tel est le cas, une suppression logique est la plus logique.
2. Y a-t-il une valeur intrinsèque dans le stockage des données? Si tel est le cas, combien de données seront générées. En fonction de cela, je choisirais soit une suppression logique, soit une stratégie d'archivage. Gardez à l'esprit que vous pouvez toujours archiver les enregistrements supprimés de manière logique.

Il est peut-être un peu tard mais je suggère à tout le monde de consulter le blog de Pinal Dave sur la suppression logique / logicielle:

Je n'aime pas du tout ce genre de design [soft delete]. Je suis fermement convaincu de l'architecture où seules les données nécessaires devraient être dans une seule table et les données inutiles devraient être déplacées vers une table archivée. Au lieu de suivre la colonne isDeleted, je suggère l'utilisation de deux tables différentes: l'une avec les commandes et l'autre avec les commandes supprimées. Dans ce cas, vous devrez maintenir à la fois la table, mais en réalité, elle est très facile à entretenir. Lorsque vous écrivez l'instruction UPDATE dans la colonne isDeleted, écrivez INSERT INTO dans une autre table et SUPPRIMEZ-la de la table d'origine. Si la situation est de retour arrière, écrivez un autre INSERT INTO et DELETE dans l'ordre inverse. Si vous craignez l'échec d'une transaction, encapsulez ce code dans TRANSACTION.

Quels sont les avantages du petit tableau par rapport au tableau plus grand dans les situations décrites ci-dessus?

• Une table plus petite est facile à entretenir
• Les opérations de reconstruction d'index sont beaucoup plus rapides
• Le déplacement des données d'archive vers un autre groupe de fichiers réduira la charge du groupe de fichiers principal (étant donné que tous les groupes de fichiers sont sur un système différent) - cela accélérera également la sauvegarde.
• Les statistiques seront fréquemment mises à jour en raison de leur taille réduite et cela nécessitera moins de ressources.
• La taille de l'index sera plus petite
• Les performances de la table s'amélioreront avec une taille de table plus petite.

Je suis un développeur NoSQL, et lors de mon dernier travail, j'ai travaillé avec des données qui étaient toujours critiques pour quelqu'un, et si elles ont été supprimées par accident le jour même de leur création, je n'ai pas pu les trouver dans la dernière sauvegarde d'hier! Dans cette situation, la suppression logicielle a toujours sauvé la mise.

J'ai effectué une suppression logicielle à l'aide d'horodatages, en enregistrant la date à laquelle le document a été supprimé:

IsDeleted = 20150310  //yyyyMMdd

Chaque dimanche, un processus marchait sur la base de données et vérifiait le IsDeletedterrain. Si la différence entre la date actuelle et l'horodatage était supérieure à N jours, le document était définitivement supprimé. Étant donné que le document était toujours disponible sur une sauvegarde, il était prudent de le faire.

ÉDITER: Ce cas d'utilisation NoSQL concerne de gros documents créés dans la base de données, des dizaines ou des centaines chaque jour, mais pas des milliers ou des millions. En général, il s'agissait de documents avec le statut, les données et les pièces jointes des processus de flux de travail. C'était la raison pour laquelle il y avait la possibilité qu'un utilisateur supprime un document important. Cet utilisateur peut être quelqu'un avec des privilèges d'administrateur, ou peut-être le propriétaire du document, pour n'en nommer que quelques-uns.

TL; DR Mon cas d'utilisation n'était pas le Big Data. Dans ce cas, vous aurez besoin d'une approche différente.

Un modèle que j'ai utilisé consiste à créer une table miroir et à attacher un déclencheur sur la table primaire, de sorte que toutes les suppressions (et mises à jour si vous le souhaitez) sont enregistrées dans la table miroir.

Cela vous permet de «reconstruire» les enregistrements supprimés / modifiés, et vous pouvez toujours supprimer définitivement dans la table primaire et la garder «propre» - cela permet également la création d'une fonction «annuler», et vous pouvez également enregistrer la date, l'heure , et l'utilisateur qui a fait l'action dans la table miroir (inestimable dans les situations de chasse aux sorcières).

L'autre avantage est qu'il n'y a aucune chance d'inclure accidentellement des enregistrements supprimés lors de l'interrogation hors du primaire, à moins que vous ne vous donniez délibérément la peine d'inclure des enregistrements de la table miroir (vous voudrez peut-être afficher les enregistrements en direct et supprimés).

Un autre avantage est que la table miroir peut être purgée indépendamment, car elle ne doit avoir aucune référence de clé étrangère réelle, ce qui en fait une opération relativement simple par rapport à la purge d'une table primaire qui utilise des suppressions logicielles mais qui a toujours des connexions référentielles à d'autres tables.

Quels autres avantages? - super si vous avez un groupe de codeurs travaillant sur le projet, faisant des lectures sur la base de données avec des compétences et une attention mitigées aux niveaux de détail, vous n'avez pas à rester éveillé en espérant que l'un d'eux n'oublie pas de ne pas inclure supprimé records (lol, Not Include Deleted Records = True), ce qui entraîne des choses comme surestimer la position de trésorerie disponible des clients avec laquelle ils vont ensuite acheter des actions (c'est-à-dire, comme dans un système de trading), lorsque vous travaillez avec des systèmes de trading, vous découvrira très rapidement la valeur des solutions robustes, même si elles peuvent avoir un "overhead" initial un peu plus élevé.

Exceptions:
- à titre indicatif, utilisez des suppressions logicielles pour les données "de référence" telles que l'utilisateur, la catégorie, etc., et des suppressions matérielles dans une table miroir pour les données de type "fait", c'est-à-dire l'historique des transactions.

J'utilise couramment des suppressions logiques - je trouve qu'elles fonctionnent bien lorsque vous archivez également par intermittence les données `` supprimées '' dans une table archivée (qui peut être recherchée si nécessaire), n'ayant ainsi aucune chance d'affecter les performances de l'application.

Cela fonctionne bien parce que vous avez toujours les données si jamais vous êtes audité. Si vous le supprimez physiquement, il est parti !

Je suis un grand fan de la suppression logique, en particulier pour une application Line of Business, ou dans le contexte de comptes utilisateurs. Mes raisons sont simples: souvent, je ne veux plus qu'un utilisateur puisse utiliser le système (le compte est donc marqué comme supprimé), mais si nous supprimions l'utilisateur, nous perdrions tout son travail et autres.

Un autre scénario courant est que les utilisateurs peuvent être recréés un certain temps après avoir été supprimés. C'est une expérience beaucoup plus agréable pour l'utilisateur d'avoir toutes ses données présentes telles qu'elles étaient avant qu'elles ne soient supprimées, plutôt que d'avoir à les recréer.

Je pense généralement que la suppression des utilisateurs les "suspend" indéfiniment. Vous ne savez jamais quand ils auront légitimement besoin d'être de retour.

Je supprime presque toujours et voici pourquoi:

• vous pouvez restaurer les données supprimées si un client vous le demande. Des clients plus satisfaits grâce aux suppressions logicielles. La restauration de données spécifiques à partir de sauvegardes est complexe
• vérifier isdeletedpartout n'est pas un problème, vous devez de useridtoute façon vérifier (si la base de données contient des données de plusieurs utilisateurs). Vous pouvez appliquer le contrôle par code, en plaçant ces deux contrôles sur une fonction distincte (ou en utilisant des vues)
• suppression gracieuse. Les utilisateurs ou les processus traitant du contenu supprimé continueront à le «voir» jusqu'à ce qu'ils atteignent la prochaine actualisation. C'est une fonctionnalité très souhaitable si un processus traite des données qui sont soudainement supprimées
• synchronisation: si vous avez besoin de concevoir un mécanisme de synchronisation entre une base de données et des applications mobiles, vous trouverez les suppressions logicielles beaucoup plus faciles à mettre en œuvre

Re: "Est-ce sécurisé?" - cela dépend de ce que vous voulez dire.

Si vous voulez dire qu'en effectuant une suppression physique, vous empêcherez quiconque de trouver les données supprimées , alors oui, c'est plus ou moins vrai; vous êtes plus sûr de supprimer physiquement les données sensibles qui doivent être effacées, car cela signifie qu'elles ont définitivement disparu de la base de données. (Cependant, sachez qu'il peut y avoir d'autres copies des données en question, comme dans une sauvegarde, ou le journal des transactions, ou une version enregistrée en transit, par exemple un renifleur de paquets - ce n'est pas parce que vous supprimez de votre base de données garantir qu'il n'a pas été enregistré ailleurs.)

Si vous voulez dire qu'en effectuant une suppression logique, vos données sont plus sécurisées car vous ne perdrez jamais aucune donnée , c'est également vrai. C'est bon pour les scénarios d'audit; J'ai tendance à concevoir de cette façon parce que cela admet le fait fondamental qu'une fois que les données sont générées, elles ne disparaîtront jamais vraiment (surtout si elles ont jamais eu la capacité d'être, par exemple, mises en cache par un moteur de recherche Internet). Bien sûr, un vrai scénario d'audit exige que non seulement les suppressions soient logiques, mais que les mises à jour soient également consignées, avec l'heure du changement et l'acteur qui a effectué le changement.

Si vous voulez dire que les données ne tomberont pas entre les mains de quiconque n'est pas censé les voir, cela dépend totalement de votre application et de sa structure de sécurité. À cet égard, la suppression logique n'est ni plus ni moins sécurisée que tout autre élément de votre base de données.

Je ne suis pas du tout d' accord avec la suppression logique car vous êtes exposé à de nombreuses erreurs.

Tout d'abord, chaque requête doit prendre en compte le champ IsDeleted et la possibilité d'erreur augmente avec les requêtes complexes.

Deuxièmement, les performances: imaginez une table avec 100000 enregistrements avec seulement 3 actifs, multipliez maintenant ce nombre pour les tables de votre base de données; un autre problème de performances est un conflit possible avec les nouveaux enregistrements avec les anciens (enregistrements supprimés).

Le seul avantage que je vois est l'historique des enregistrements, mais il existe d'autres méthodes pour obtenir ce résultat, par exemple, vous pouvez créer une table de journalisation où vous pouvez enregistrer les informations: TableName,OldValues,NewValues,Date,User,[..]où *Valuespeut-on être varcharet écrire les détails dans ce formulaire fieldname : value; [..] ou enregistrez les informations sous xml.

Tout cela peut être réalisé via le code ou Triggers mais vous êtes seulement UNE table avec toute votre histoire. Une autre option consiste à voir si le moteur de base de données spécifié prend en charge nativement le suivi des modifications, par exemple sur la base de données SQL Server, il existe SQL Track Data Change.

J'avais l'habitude de faire des suppressions logicielles, juste pour conserver les anciens enregistrements. J'ai réalisé que les utilisateurs ne se donnaient pas la peine de voir les anciens enregistrements aussi souvent que je le pensais. Si les utilisateurs souhaitent afficher les anciens enregistrements, ils peuvent simplement les afficher à partir d'une table d'archive ou d'audit, n'est-ce pas? Alors, quel est l'avantage de la suppression logicielle? Cela ne conduit qu'à une instruction de requête plus complexe, etc.

Voici les choses que j'ai implémentées, avant de décider de ne plus supprimer à la volée:

1. mettre en œuvre un audit, pour enregistrer toutes les activités (ajouter, modifier, supprimer). Assurez-vous qu'il n'y a pas de clé étrangère liée à l'audit, et assurez-vous que cette table est sécurisée et que personne ne peut supprimer sauf les administrateurs.

2. identifier quelles tables sont considérées comme des «tables transactionnelles», lesquelles sont très probablement conservées pendant longtemps, et très probablement l'utilisateur voudra peut-être consulter les enregistrements ou rapports passés. Par exemple; transaction d'achat. Cette table ne doit pas seulement conserver l'identifiant de la table principale (telle que dept-id), mais également conserver les informations supplémentaires telles que le nom comme référence (telle que dept-name) ou tout autre champ nécessaire pour la création de rapports.

3. Implémentez l'enregistrement «actif / inactif» ou «activer / désactiver» ou «masquer / afficher» de la table maître. Ainsi, au lieu de supprimer l'enregistrement, l'utilisateur peut désactiver / inactiver l'enregistrement principal. C'est beaucoup plus sûr de cette façon.

Juste mon avis de deux cents.

Les suppressions logiques sont difficiles pour l'intégrité référentielle.

C'est la bonne pensée à faire quand il y a un aspect temporel des données de la table (sont valides FROM_DATE - TO_DATE).

Sinon, déplacez les données vers une table d'audit et supprimez l'enregistrement.

Du coté positif:

C'est le moyen le plus simple de revenir en arrière (si possible).

Il est facile de voir quel était l'état à un moment donné.

C'est assez standard dans les cas où vous souhaitez conserver un historique de quelque chose (par exemple, les comptes d'utilisateurs comme le mentionne @Jon Dewees). Et c'est certainement une excellente idée s'il y a de fortes chances que les utilisateurs demandent des annulations.

Si vous craignez que la logique du filtrage des enregistrements supprimés de vos requêtes ne devienne compliquée et ne complique vos requêtes, vous pouvez simplement créer des vues qui effectuent le filtrage à votre place et utiliser des requêtes à cet effet. Cela empêchera la fuite de ces enregistrements dans les solutions de reporting et autres.

Il existe des exigences au-delà de la conception du système auxquelles il faut répondre. Quelle est l'exigence légale ou statutaire de la conservation des enregistrements? En fonction de ce à quoi les lignes sont liées, il peut y avoir une obligation légale que les données soient conservées pendant un certain temps après avoir été «suspendues».

D'un autre côté, l'exigence peut être qu'une fois que l'enregistrement est «supprimé», il soit véritablement et irrévocablement supprimé. Avant de prendre une décision, parlez-en à vos parties prenantes.

Les applications mobiles qui dépendent de la synchronisation peuvent imposer l'utilisation d'une suppression logique plutôt que physique: un serveur doit être en mesure d'indiquer au client qu'un enregistrement a été (marqué comme) supprimé, et cela peut ne pas être possible si les enregistrements ont été physiquement supprimés.

Ils ne laissent pas la base de données fonctionner comme elle le devrait, ce qui rend inutile la fonctionnalité de cascade.

Pour des choses simples telles que les insertions, dans le cas d'une réinsertion, le code derrière elle double.

Vous ne pouvez pas simplement insérer, à la place, vous devez vérifier une existence et insérer si elle n'existe pas auparavant ou mettre à jour l'indicateur de suppression si c'est le cas tout en mettant à jour toutes les autres colonnes avec les nouvelles valeurs. Ceci est considéré comme une mise à jour du journal des transactions de la base de données et non comme une nouvelle insertion provoquant des journaux d'audit inexacts.

Ils entraînent des problèmes de performances car les tables sont remplies de données redondantes. Il joue des ravages avec l'indexation, en particulier avec l'unicité.

Je ne suis pas un grand fan des suppressions logiques.

Pour répondre au commentaire de Tohid, nous avons été confrontés au même problème où nous voulions conserver l'historique des enregistrements et nous ne savions pas non plus si nous voulions is_deleted colonne ou non.

Je parle de notre implémentation python et d'un cas d'utilisation similaire que nous avons rencontré.

Nous avons rencontré https://github.com/kvesteri/sqlalchemy-continuum qui est un moyen facile d'obtenir une table de gestion des versions pour votre table correspondante. Lignes de code minimum et historique des captures pour l'ajout, la suppression et la mise à jour.

Cela sert plus que juste is_deleted colonne. Vous pouvez toujours revenir à la table des versions pour vérifier ce qui s'est passé avec cette entrée. Si l'entrée a été supprimée, mise à jour ou ajoutée.

De cette façon, nous n'avions pas besoin du tout de is_deletedcolonne et notre fonction de suppression était assez simple. De cette façon, nous n'avons pas non plus besoin de nous souvenir de marquer is_deleted=Falsedans l'une de nos API.

Soft Delete est une pratique de programmation suivie dans la plupart des applications lorsque les données sont plus pertinentes. Prenons un cas d'application financière où une suppression par erreur de l'utilisateur final peut être fatale. C'est le cas lorsque la suppression logicielle devient pertinente. Dans la suppression logicielle, l'utilisateur ne supprime pas réellement les données de l'enregistrement au lieu d'être marqué comme IsDeleted à true (par convention normale).

Dans EF 6.x ou EF 7, Softdelete est ajouté en tant qu'attribut, mais nous devons créer un attribut personnalisé pour le moment.

Je recommande fortement SoftDelete dans une conception de base de données et c'est une bonne convention pour la pratique de la programmation.

La plupart du temps, la suppression logicielle est utilisée parce que vous ne voulez pas exposer certaines données mais que vous devez les conserver pour des raisons historiques (un produit peut être abandonné, vous ne voulez donc pas de nouvelle transaction avec lui, mais vous devez toujours travailler avec l'historique de la transaction de vente). À propos, certains copient la valeur des informations sur le produit dans les données de transaction de vente au lieu de faire référence au produit pour gérer cela.

En fait, cela ressemble plus à une reformulation pour une fonctionnalité visible / cachée ou active / inactive. Parce que c'est le sens de «supprimer» dans le monde des affaires. Je voudrais dire que les Terminators peuvent supprimer des personnes mais que le patron les licencie simplement.

Cette pratique est un modèle assez courant et utilisée par de nombreuses applications pour de nombreuses raisons. Comme ce n'est pas le seul moyen d'y parvenir, vous aurez donc des milliers de personnes qui disent que c'est génial ou des conneries et que les deux ont de très bons arguments.

Du point de vue de la sécurité, SoftDelete ne remplacera pas le travail d'audit et ne remplacera pas non plus le travail de sauvegarde. Si vous avez peur de "l'insertion / suppression entre deux cas de sauvegarde", vous devriez lire sur les modèles de récupération complète ou en bloc. J'admets que SoftDelete pourrait rendre le processus de récupération plus simple.

A vous de connaître votre exigence.

Pour donner une alternative, nous avons des utilisateurs utilisant des périphériques distants qui se mettent à jour via MobiLink. Si nous supprimons des enregistrements dans la base de données du serveur, ces enregistrements ne sont jamais marqués comme supprimés dans les bases de données client.

Nous faisons donc les deux. Nous travaillons avec nos clients pour déterminer combien de temps ils souhaitent pouvoir récupérer des données. Par exemple, en général, les clients et les produits sont actifs jusqu'à ce que notre client dise qu'ils doivent être supprimés, mais l'historique des ventes n'est conservé que pendant 13 mois, puis se supprime automatiquement. Le client peut souhaiter conserver les clients et produits supprimés pendant deux mois, mais conserver l'historique pendant six mois.

Nous exécutons donc un script pendant la nuit qui marque les éléments supprimés de manière logique en fonction de ces paramètres, puis deux à six mois plus tard, tout ce qui est marqué logiquement supprimé aujourd'hui sera définitivement supprimé.

Nous sommes moins sur la sécurité des données que d'avoir d'énormes bases de données sur un appareil client avec une mémoire limitée, comme un smartphone. Un client qui commande 200 produits deux fois par semaine pendant quatre ans aura plus de 81 000 lignes d'historique, dont 75% le client ne se soucie pas s'il voit.

Tout dépend du cas d'utilisation du système et de ses données.

Par exemple, si vous parlez d'un système réglementé par le gouvernement (par exemple, un système dans une entreprise pharmaceutique qui est considéré comme faisant partie du système de qualité et doit suivre les directives de la FDA pour les enregistrements électroniques), alors vous feriez bien mieux de ne pas faire de suppression définitive! Un auditeur de la FDA peut entrer et demander tous les enregistrements du système relatifs au numéro de produit ABC-123, et toutes les données seront mieux disponibles. Si le propriétaire de votre processus métier déclare que le système ne devrait autoriser personne à utiliser le numéro de produit ABC-123 sur de nouveaux enregistrements à l'avenir, utilisez plutôt la méthode de suppression réversible pour le rendre "inactif" dans le système, tout en conservant les données historiques.

Cependant, peut-être que votre système et ses données ont un cas d'utilisation tel que «suivre la météo au pôle Nord». Peut-être que vous prenez des lectures de température une fois par heure, et à la fin de la journée, agréger une moyenne quotidienne. Peut-être que les données horaires ne seront plus jamais utilisées après l'agrégation et que vous supprimeriez définitivement les lectures horaires après avoir créé l'agrégat. (Ceci est un exemple inventé et trivial.)

Le fait est que tout dépend du cas d'utilisation du système et de ses données, et non d'une décision à prendre uniquement d'un point de vue technologique.

Bien! Comme tout le monde l'a dit, cela dépend de la situation.

Si vous avez un index sur une colonne comme UserName ou EmailID - et que vous ne vous attendez jamais à ce que le même UserName ou EmailID soit utilisé à nouveau; vous pouvez opter pour une suppression logicielle.

Cela dit, vérifiez toujours si votre opération SELECT utilise la clé primaire. Si votre instruction SELECT utilise une clé primaire, l'ajout d'un indicateur avec la clause WHERE ne ferait pas beaucoup de différence. Prenons un exemple (Pseudo):

Utilisateurs de la table (UserID [clé primaire], EmailID, IsDeleted)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

Cette requête ne fera aucune différence en termes de performances car la colonne UserID a une clé primaire. Initialement, il analysera la table en fonction de PK, puis exécutera la condition suivante.

Cas où les suppressions logicielles ne peuvent pas du tout fonctionner:

Inscrivez-vous sur la plupart des sites Web utilisent EmailID comme votre identification unique. Nous savons très bien qu'une fois qu'un EmailID est utilisé sur un site Web comme Facebook, G +, il ne peut être utilisé par personne d'autre.

Il arrive un jour où l'utilisateur souhaite supprimer son profil du site Web. Maintenant, si vous effectuez une suppression logique, cet utilisateur ne pourra plus jamais s'inscrire. De plus, vous réinscrire en utilisant le même EmailID ne signifierait pas restaurer l'intégralité de l'historique. Tout le monde le sait, la suppression signifie la suppression. Dans de tels scénarios, nous devons effectuer une suppression physique. Mais afin de conserver l'historique complet du compte, nous devons toujours archiver ces enregistrements dans des tables d'archive ou des tables supprimées.

Oui, dans les situations où nous avons beaucoup de tables étrangères, la manipulation est assez lourde.

Gardez également à l'esprit que les suppressions logiques / logiques augmenteront la taille de votre table, donc la taille de l'index.

J'ai déjà répondu dans un autre post . Cependant, je pense que ma réponse correspond mieux à la question ici.

Ma solution pratique pour la suppression en douceur est l' archivage en créant une nouvelle table avec les colonnes suivantes: original_id, table_name, payload, (et une clé primaire en option `id).

Où original_idest l'ID d'origine de l'enregistrement supprimé, table_name est le nom de table de l'enregistrement supprimé ( "user"dans votre cas), payloadest la chaîne JSON-stringified de toutes les colonnes de l'enregistrement supprimé.

Je suggère également de faire un index sur la colonne original_idpour la dernière récupération de données.

Par cette manière d'archiver les données. Vous aurez ces avantages

• Gardez une trace de toutes les données de l'historique
• Avoir un seul endroit pour archiver les enregistrements de n'importe quelle table, quelle que soit la structure de table de l'enregistrement supprimé
• Pas de souci d'index unique dans la table d'origine
• Pas de souci de vérifier l'index étranger dans la table d'origine
• Plus de WHEREclause dans chaque requête pour vérifier la suppression

Il y a déjà une discussion ici expliquant pourquoi la suppression logicielle n'est pas une bonne idée en pratique. La suppression logicielle introduit des problèmes potentiels à l'avenir tels que le comptage des enregistrements, ...

Les aventages sont la préservation / perpétuation des données. Une suppression serait une diminution des performances lors de l'interrogation ou de la récupération de données à partir de tables avec une quantité significative de suppressions logicielles. Dans notre cas, nous utilisons une combinaison des deux: comme d'autres l'ont mentionné dans les réponses précédentes, nous soft-delete users/clients/customerspar exemple, et hard-deletesur les items/products/merchandisetables où il y a des enregistrements dupliqués qui n'ont pas besoin d'être conservés.

Cela dépend du cas, considérez ce qui suit:

En général, vous n'avez pas besoin de "supprimer" un enregistrement. Restez simple et rapide. Par exemple, la suppression d'un produit n'est plus disponible, vous n'avez donc pas à vérifier que le produit n'est pas supprimé de manière réversible dans toute votre application (nombre, liste de produits, produits recommandés, etc.).

Pourtant, vous pouvez envisager la «suppression logicielle» dans un modèle d'entrepôt de données. Par exemple, vous consultez un ancien reçu sur un produit supprimé. *