Faut-il jamais supprimer des données dans une base de données?
Je suis nouveau dans les bases de données et j'essaie de comprendre les concepts de base. J'ai appris à supprimer des données dans une base de données. Mais un de mes amis m'a dit que vous ne devriez jamais supprimer de données dans une base de données. Au contraire, lorsqu'il n'est plus nécessaire, il est préférable de simplement le marquer ou de le signaler comme "non utilisé".
Est-ce vrai? Si oui, comment une grande entreprise comme IBM traiterait-elle ses données pendant cent ans ou plus?
Comme pour toutes ces choses, la réponse est "cela dépend".
Si l'utilisateur est susceptible de vouloir récupérer les données, vos amis ont raison - vous ne supprimez pas vraiment, marquez simplement l'enregistrement comme "supprimé". De cette façon, lorsque l'utilisateur change d'avis, vous pouvez récupérer les données.
Cependant, si les données supprimées datent de plus d'une certaine période (un an par exemple), vous pouvez décider de les supprimer réellement des tables en direct, mais de les conserver dans une table d'archives ou même juste en cas de sauvegarde si l'utilisateur le souhaite. retour. De cette façon, vous pouvez réduire au minimum la quantité de données (en direct et récemment supprimées).
Cependant, si les données sont éphémères ou facilement recréées, vous pouvez très bien décider de supprimer réellement les données.
Il y a une classe de données que vous avez à supprimer - et ce sont les données personnelles que l'utilisateur ne veut plus que vous conserviez. Il peut y avoir des lois locales (par exemple dans l'UE) qui en font une exigence obligatoire (merci Gavin )
De même, il peut y avoir des règles qui vous obligent à ne pas supprimer les données, donc avant de décider quoi que ce soit, vérifiez auprès des autorités réglementaires ce que vous devez faire pour vous conformer aux loi.
Il s'agit en fait d'un problème important pour de nombreuses entreprises. Il n'y a aucun moyen de déterminer proprement quelles données sont réellement utilisées, donc elles se trouvent simplement dans la base de données. La suppression et l'archivage des données doivent faire partie de chaque grande conception de système, mais c'est rarement le cas. La plupart des entreprises ne font que vivre avec, achetant de plus gros disques et ajustant leurs requêtes et index pour maintenir les performances, jusqu'à ce qu'elles changent de système, puis qu'elles fassent beaucoup d'efforts pour identifier les données actuelles, puis migrent uniquement ces enregistrements vers leur nouveau système.
Oui, vous devriez supprimer des données de votre base de données, mais il n'est souvent pas simple de dire quoi et quand.
Il y a déjà eu beaucoup de bonnes réponses à cela qui se résument à peu près à "Cela dépend des circonstances", et je ne peux rien y ajouter.
Une chose qui n'a pas été mentionnée, cependant, qui, je pense, doit être mentionnée, est que vous ne devriez jamais réutiliser des clés primaires qui ont été générées par une séquence ou un système AUTO_INCREMENT.
Lorsque vous supprimez un élément auquel une telle clé primaire avait été affectée par un tel système, il y aura des lacunes dans la colonne de clé primaire, laissées par les données supprimées. Il y a une grande tentation de réaffecter ces lacunes à de nouveaux éléments à mesure qu'ils sont ajoutés, ou pire encore, de mélanger les données existantes pour lui donner un nouvel ID pour supprimer les lacunes, mais cela entraînera des problèmes que vous auriez vous n'aurez jamais à vous en occuper si vous venez de laisser les clés seules.
Supposons que vous conserviez une base de données d'imprimantes pour gérer la réorganisation des consommables. L'imprimante 13, une ancienne imprimante laser, tombe en panne au-delà de la réparation économique, vous la jetez donc. Pendant ce temps, pour une raison indépendante, quelqu'un commande une nouvelle imprimante thermique pour faire l'impression de codes à barres dans l'entrepôt, et cette imprimante arrive avant le remplacement de l'imprimante 13. L'administrateur enregistre cette nouvelle imprimante dans la base de données et, parce que 13 est maintenant gratuit et vous recyclez les identifiants, la nouvelle imprimante thermique obtient 13 comme identifiant.
Maintenant, quelqu'un vous dit que l'imprimante 13 n'a presque plus d'encre. Vous vous souvenez que l'imprimante 13 est une imprimante laser, vous n'avez donc pas la peine de la rechercher dans la base de données et vous passez une commande de cartouche de toner. Seulement vous aviez réellement besoin de commander un pack d'encre thermique car l'imprimante 13 n'est plus une imprimante laser. Lorsque la cartouche de toner arrive, vous ne pouvez pas l'utiliser car il s'agit d'une mauvaise recharge d'encre pour l'imprimante, vous ne pouvez plus imprimer de codes à barres et vous ne pouvez pas expédier de commandes en attente d'être expédiées.
Pire encore, que se passe-t-il si vous supprimez l'imprimante 13 et mélangez toutes les imprimantes qui la suivent pour combler l'écart? L'imprimante 14 (une ancienne matrice de points décrépite) devient l'imprimante 13, l'imprimante 15 devient l'imprimante 14 et ainsi de suite.
Toutes les imprimantes ont des étiquettes afin qu'elles puissent être croisées avec la base de données, mais maintenant toutes les étiquettes sont obsolètes. Vous devrez faire le tour, localiser toutes les imprimantes de l'entreprise (qui pourraient en compter des centaines!) Et les renommer. Ce n'est guère une utilisation efficace du temps. Et c'est aussi un processus sujet aux erreurs, et que se passe-t-il si cela ne se fait jamais? Quelqu'un appelle pour dire que l'imprimante 14 est tombée en panne et doit être réparée de toute urgence, alors recherchez-la et constatez que l'imprimante 14 est une imprimante à jet d'encre à la réception. Ce n'est que parce que vous avez mélangé les identifiants que c'est l'imprimante à matrice de points qui doit être réparée de toute urgence. Le gars qui a appelé le problème est suspendu, tandis que la réceptionniste a un gars du support technique qu'elle n'a jamais appelé pour réparer une imprimante qui n'était pas cassée.
Vous devriez considérer les identifiants attribués par un système d'incrémentation automatique comme permanents, ils sont immuables et ne peuvent pas être réutilisés, même si la chose à laquelle l'ID fait référence cesse d'exister. Certaines personnes affirment qu'elles ne veulent pas avoir à s'inquiéter de la fin des ID, mais même avec des systèmes 32 bits et des ID signés, il reste encore environ 2 milliards d'ID disponibles. Si vous pouvez rendre la colonne ID non signée, cela double à 4 milliards, et sur les systèmes 64 bits, le nombre d'ID disponibles est littéralement supérieur au nombre d'étoiles dans le ciel. Vous n'allez pas manquer d'ID.
Beaucoup de bonnes réponses ici déjà. Je veux juste ajouter une situation que personne n'a encore mentionnée:
données sensibles. Si l'utilisateur le supprime, vous feriez mieux de le supprimer!
Une situation très courante qui me vient à l'esprit est le changement/réinitialisation du mot de passe. Vous ne voudriez pas stocker d'anciens mots de passe (même s'ils sont hachés, salés, etc.) dans votre base de données. Les utilisateurs peuvent utiliser leurs anciens (et mauvais) mots de passe sur d'autres sites.
En outre, en ce qui concerne les lois concernant la durée pendant laquelle vous êtes autorisé à stocker certains types de données, les suppressions en douceur ne le feront bien sûr pas. Vous devez réellement le supprimer.
Je me demande donc: l'utilisateur (ou quelqu'un d'autre, le gouvernement par exemple) sera-t-il fou si je lui fais croire que les données ont été supprimées, mais en fait je les ai toujours et je peux les restaurer à tout moment?
Je ne supprime généralement pas les données utilisateur dans mes bases de données. Je les signale pour qu'ils soient cachés. Trop souvent, un utilisateur supprime quelque chose accidentellement et a besoin de le remplacer facilement. Il permet également de conserver l'intégrité référentielle des données associées. Cela fonctionne pour les bases de données de petite à moyenne taille. Dans les systèmes où les performances sont fortement affectées par cette décision, elles sont traitées de manière particulière, par ex. tables d'archives, sauvegardes automatisées, etc.
Nous supprimons les données de backend si nécessaire, par exemple données de session de site Web expirées et anciennes informations de journal. Il ne sert à rien de les garder pour toujours.
Comme d'habitude, cependant, la réponse exacte dépend vraiment de la situation spécifique.
Dans la majorité des cas, vous devez conserver les données au cas où elles seraient nécessaires à l'avenir. L'entreprise pour laquelle vous travaillez peut vouloir regarder les données historiques pour baser ses décisions sur lesquelles orientera la société dans une certaine direction.
Vous devez ajouter des colonnes "Date_Time_Removed" à chaque table, puis au lieu de supprimer physiquement la ou les lignes, vous définissez une date et une heure auxquelles la ligne a été virtuellement supprimée. Ensuite, dans vos procédures stockées ou sql, vous tiendriez compte de la colonne 'Date_Time_Removed', par exemple sélectionnez blah dans table1 où date_time_removed est nul
Bien sûr, les lignes qui ont été accidentellement ajoutées à une base de données doivent être supprimées définitivement, en particulier les données de test.
En conservant toutes les données légitimes, vous avez également la possibilité d'utiliser votre base de données pour l'entreposage à l'avenir.
Une autre situation que les autres présentées est lorsque les données sont supprimées, mais les journaux des opérations effectuées dans la base de données (suppression incluse) sont stockés dans des archives pendant une longue période. Le principal objectif de cela est la mise en œuvre d'un système de restauration aux dates passées, mais il peut également être utilisé pour stocker d'une manière ou d'une autre des données supprimées (qui sont supprimées de la base de données, mais stockées dans des archives).
Le stockage d'archives de données supprimées ne serait pas si important. Les grandes entreprises peuvent également stocker des versions de code et beaucoup plus d'informations (sans parler de choses non techniques), donc au final, le stockage de grandes données est quelque chose d'ordinaire pour elles.
Je travaille sur une application de change depuis quelques années où cela est arrivé. Les données que l'application a recueillies au fil des ans ont eu un impact sur les performances (disons exponentielles).
Après avoir fait ce que nous pouvions en termes de code, nous avons proposé à la gestion d'archiver les données datant de plus d'un an. Ils ont vérifié le concept (questions juridiques) et heureusement, nous avons pu le faire. Nous avons donc supprimé, mais nous avons également archivé les données afin que les entreprises puissent toujours exécuter leurs rapports, etc.