Devrions-nous jamais supprimer des données dans une base de données?

Je suis novice 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 de ne jamais supprimer de données dans une base de données. Au lieu de cela, quand 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 tel est le cas, comment une grande entreprise comme IBM gérerait-elle ses données pendant cent ans ou plus?

Comme pour toutes ces choses, la réponse est "ça dépend".

S'il est probable que l'utilisateur souhaite récupérer les données, vos amis ont raison: vous ne supprimez pas vraiment, il vous suffit de marquer l'enregistrement comme "supprimé". Ainsi, lorsque l'utilisateur change d'avis, vous pouvez récupérer les données.

Toutefois, si les données supprimées datent de plus d'une certaine période (une année par exemple), vous pouvez décider de les supprimer réellement des tables actives, mais de les conserver dans une table d'archivage ou même de les sauvegarder si l'utilisateur le souhaite. le retour. De cette manière, vous pouvez réduire au minimum la quantité de données (en direct et récemment supprimées).

Toutefois, si les données sont éphémères ou faciles à recréer, vous pouvez décider de les supprimer.

Il existe une classe de données que vous devez supprimer - et il s'agit de données personnelles que l'utilisateur ne souhaite plus conserver. 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 exister des règles vous interdisant de supprimer des données. Avant de décider quoi que ce soit, vérifiez auprès des autorités de régulation de ce que vous devez faire pour vous conformer à la loi.

C'est en fait un problème important pour beaucoup d'entreprises. Il n'y a aucun moyen de déterminer proprement quelles données sont réellement utilisées, elles sont donc simplement stockées dans la base de données. La suppression et l'archivage des données doivent faire partie de toute conception de système de grande taille, mais c'est rarement le cas. La plupart des entreprises vivent avec, achetant de plus gros disques et peaufinant leurs requêtes et index pour maintenir leurs performances, jusqu'à ce qu'elles changent de système, puis qu'elles déploient beaucoup d'efforts pour identifier les données actuelles et ne migrent ensuite ces enregistrements que sur leur nouveau système.

Oui, vous devez supprimer les données de votre base de données, mais il est souvent simple de dire quoi et quand.

Il y a déjà eu beaucoup de bonnes réponses à cette question qui se résument à "Cela dépend des circonstances", et je ne peux rien y ajouter.

Une chose qui n’a pas été mentionnée, cependant, et qui, à mon avis, mérite d’être mentionnée, est que vous ne devriez jamais réutiliser des clés primaires générées par une séquence ou un système AUTO_INCREMENT.

Lorsque vous supprimez un élément auquel une clé primaire a été affectée par un tel système, il y aura des trous dans la colonne de clé primaire, laissée par les données supprimées. La tentation est grande de réattribuer ces lacunes à de nouveaux éléments au fur et à mesure de leur ajout ou, pire encore, de mélanger les données existantes pour leur attribuer un nouvel identifiant afin de les éliminer, mais cela entraînerait des problèmes ne jamais avoir à traiter si vous venez de laisser les clés seul.

Supposons que vous gardiez une base d'imprimantes pour gérer les consommables de réorganisation. L’imprimante 13, une ancienne imprimante laser, tombe en panne de manière économique, vous la jetez donc à la poubelle. Pendant ce temps, pour une raison quelconque, quelqu'un commande une nouvelle imprimante thermique pour 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, étant donné que 13 est maintenant gratuit et vous recyclez les ID, la nouvelle imprimante thermique se voit attribuer 13 comme ID.

Maintenant, quelqu'un vous dit que l'imprimante 13 est presque vide. Vous vous rappelez que l’imprimante 13 est une imprimante laser, vous ne cherchez donc pas dans la base de données et vous commandez une cartouche de toner. Vous n’aviez réellement besoin que de commander un paquet d’encre thermique, car l’imprimante 13 n’est plus une imprimante laser. Lorsque la cartouche de toner arrive, vous ne pouvez plus l’utiliser car il s’agit d’une mauvaise recharge d’encre pour l’imprimante. Vous ne pouvez plus imprimer de codes à barres ni expédier de commandes en attente d’expédition.

Pire encore, que se passe-t-il si vous supprimez l'imprimante 13 et que vous mélangez toutes les imprimantes qui le suivent pour combler le vide? L'imprimante 14 (une vieille matrice de points décrépit) devient l'imprimante 13, l'imprimante 15 devient l'imprimante 14 et ainsi de suite.

Toutes les imprimantes ont des étiquettes sur elles afin qu'elles puissent être référencé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 contenir des centaines!) Et les renommer. Ce n'est pas 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 en panne et doit être réparée de toute urgence. Vous devez donc vérifier si l'imprimante 14 est une imprimante à jet d'encre en réception. Seulement parce que vous avez mélangé les identifiants, c'est en fait l'imprimante matricielle qui doit être réparée de toute urgence. Le gars qui a appelé le problème reste en suspens, alors que la réceptionniste a un technicien du support technique qu'elle n'a jamais appelé pour venir réparer une imprimante qui n'était pas en panne.

Les identifiants attribués par un système à incrémentation automatique doivent être considérés comme permanents, ils sont immuables et ne peuvent pas être réutilisés, même si l'élément auquel l'identifiant fait référence cesse d'exister. Certaines personnes affirment ne pas vouloir s'inquiéter du manque d'identifiants, mais même avec des systèmes 32 bits et des identifiants signés, il reste environ 2 milliards d'identifiants disponibles. Si vous pouvez supprimer la signature de la colonne ID, le nombre d'ID disponibles sur les systèmes 64 bits est littéralement supérieur au nombre d'étoiles dans le ciel. Vous n'allez pas manquer d'identifiants.

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 les 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, bien entendu, les suppressions douces ne le seront pas. Vous devez réellement le supprimer.

Je me demandais donc si l'utilisateur (ou quelqu'un d'autre, le gouvernement par exemple) serait furieux si je leur fais croire que les données ont été supprimées, mais en fait je les ai toujours et je peux les restaurer à tout moment.

En général, je ne supprime pas les données utilisateur dans mes bases de données. Je leur signale qu'ils sont cachés. Trop souvent, un utilisateur supprime quelque chose accidentellement et doit le remplacer facilement. Cela permet également de conserver l'intégrité référentielle pour les données associées. Cela fonctionne pour les bases de données de taille petite à moyenne. Dans les systèmes où les performances sont fortement affectées par cette décision, elles sont gérées de manière particulière, telles que les tables d'archivage, les sauvegardes automatisées, etc.

Nous supprimons les données principales si nécessaire, par exemple les données de session de site Web expirées et les anciennes informations de journal. Il ne sert à rien de les garder pour toujours.

Comme d'habitude, la réponse exacte dépend vraiment de la situation.

Je travaille sur une application d'échange de devises étrangères depuis deux ans. Les données que l'application a collectées au fil des ans ont eu un impact sur les performances (disons exponentionnelles).

Après avoir fait notre possible en termes de code, nous avons proposé à la direction d’archiver des données datant de plus d’un an. Ils ont vérifié le concept (problèmes 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.

Dans la majorité des cas, vous devez conserver les données au cas où vous en auriez besoin ultérieurement. L’entreprise pour laquelle vous travaillez peut souhaiter consulter les données historiques afin de prendre des décisions qui guideront l’entreprise dans une certaine direction.

Vous devez ajouter des colonnes "Date_Time_Removed" à chaque table et, au lieu de supprimer physiquement la ou les lignes, vous définissez une date et une heure de suppression virtuelle de la ligne. Ensuite, dans vos procédures stockées ou SQL, vous devez inclure la colonne "Date_Time_Removed", par exemple, sélectionnez blah dans table1 où date_time_removed est null

Bien sûr, les lignes qui ont été ajoutées accidentellement à 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 ultérieur.

Une autre situation que les autres présentées est celle où 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. La principale tâche consiste à implémenter un système de restauration des dates antérieures, 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).

Stocker des archives de données supprimées ne serait pas une grosse affaire. Les grandes entreprises peuvent également stocker des versions de code et de nombreuses autres informations (pour ne pas parler d'éléments non techniques), de sorte que stocker des données volumineuses est quelque chose d'habituel.