Salut, c'est Nico de Code Garage et bienvenue dans ce nouvel épisode du podcast.
Code Garage, qu'est-ce que c'est ? C'est une plateforme de formation où vous payez
un tarif mensuel 19h99 par mois pour avoir accès à tous nos cours en illimité, donc
avoir accès à des cours complets pour continuer à se former toujours et compléter vos cours
de formation ou simplement continuer votre apprentissage et ce avec des cours vraiment
hyper qualitatifs.
Aujourd'hui dans cet épisode, on va parler du concept de softdilite en base de données.
En base de données, que vous soyez en SQL ou en SQL, pour supprimer une donnée, vous
allez simplement utiliser la commande prévue pour ça.
En SQL, par exemple, c'est dillite from et puis en SQL, ça va dépendre de la base
de données et du connecteur que vous allez utiliser.
Qu'est-ce qui se passe quand vous supprimer une donnée ? Alors, on va parler notamment
dans les données relationnelles, même si le softdilite est valable dans les deux, mais
en relationnel, quand vous avez une relation entre deux tables, quand vous allez supprimer
la donnée qui est référencée par une autre table, vous avez deux choix.
C'est vous qui allez choisir, soit vous allez laisser l'autre donnée vivre, elle va continuer
d'exister mais la relation ne va plus exister, soit vous décidez, c'est simple, quand je
supprime la donnée qui est référencée, ça supprime la donnée aussi qui est référence.
Le problème de ça, c'est que parfois on a besoin, en fait, pour des raisons x, y,
de garder plus ou moins ces deux données ou en tout cas certaines métadonnées.
Je prends un exemple juste tout bête.
Par exemple, quand un utilisateur supprime son compte, on va potentiellement vouloir
garder les contenus qu'il a produit parce que ça, on a le droit, sauf si il le demande
explicitement, mais on va dire, on va garder les contenus qu'il a fait.
Le problème, c'est que si vous supprimez simplement l'utilisateur en gardant tous
les contenus, donc où il est référencé en tant qu'auteur, il y a des chances que,
dans votre système logique, dans toutes vos règles logiques, vous lier récupérer le
nom de l'auteur et donc, comme cet objet-là n'existe plus, peut-être soit votre application
va cracher, soit elle va afficher du blanc, enfin pas de texte, puisque on n'a plus le nom
de l'auteur, il n'est plus disponible dans la base de données.
Donc ça peut poser des problèmes de cohérence et d'intégrité de données.
Donc ça, ce sont des choses qui se réfléchissent à la conception de la base de données,
mais toujours est-il qu'il y a parfois des moments où on se dit, en fait,
cette donnée doit être supprimée, mais si jamais il y a un problème ou pour x ou y raison,
j'aimerais quand même garder ces données ou une partie de ces données.
Et bien ça, c'est ce qu'on va appeler le soft delete.
Le soft delete, ça consiste tout simplement à modifier un petit peu votre schéma de base de données
en ajoutant, pour chaque table, chaque collection, peu importe,
une nouvelle colonne, un nouveau champ qu'on va appeler isdilité,
de vous diliter, de vous peu importe, mais en tout cas une information qui indique
si la donnée est supprimée ou non.
Donc en fait, ce qui va se passer, c'est qu'on ne va jamais réellement supprimer la
donnée de notre base de données.
On va simplement ajouter une information en disant, oui, cette donnée-là, elle est bien supprimée.
Et donc, on va faire un filtre sur toutes nos requêtes, toutes les requêtes qui sont construites
dans la base de données, en disant, par exemple, quand je liste tous les utilisateurs,
j'en sais rien, on va lister tous les utilisateurs qui ne sont pas supprimés,
qui n'ont pas cette colonne supprimée.
Ça, c'est ce qu'on appelle le soft delete.
Et donc, ça nous permet de garder toutes les informations comme on les avait avant.
Ok ? Donc c'est hyper pratique parce que, que ce soit pour les statistiques,
que ce soit, comme je le disais, pour les anciennes relations ou les choses comme ça,
eh bien, on peut conserver quasiment toute la logique de notre application telle qu'elle.
Maintenant, déjà, je sais que vous allez me dire, oui, mais on n'a pas le droit de faire ça,
surtout sur un utilisateur, on n'a pas le droit de ne pas supprimer son compte si jamais il demeure.
Alors ça, c'est évident, mais en fait, ce qui va se passer, c'est qu'une,
on va le faire uniquement sur les informations et les données,
on peut se le permettre, premièrement.
Et par exemple, pour les utilisateurs, on peut très bien imaginer qu'en fait,
on garde l'entité, on va dire du compte, mais on va le rendre anonyme par exemple, ok ?
Donc son prénom, ça va devenir anonyme, son nom, ça va devenir anonyme.
On va supprimer son email, il pourra plus se reconnecter, etc.
Et on va juste garder, on va dire, une espèce de mini coquille vide avec des données de base.
Pour tout simplement garder toute cette intégrité de données,
et simplement si jamais on se rend compte qu'on a besoin du nom de l'utilisateur,
eh bien ça va apparaître soit en anonyme,
soit vous avez déjà vu ça sur des sites par exemple,
qui affichent en tant que utilisateur supprimé.
Voilà, sur les messages d'Inforum, par exemple,
on va garder tous les messages des utilisateurs,
mais si ils suppriment leur compte,
eh bien on indique que l'utilisateur est supprimé,
mais nous on a encore la date à laquelle a été créé le compte,
peut-être la date à laquelle il a été supprimé, etc.
Ça nous permet de faire des statistiques,
de savoir éventuellement à quelle période nos utilisateurs suppriment le plus leur compte, etc.
Donc c'est sûr qu'en termes de RGPD,
de toute façon il faut supprimer toutes les données personnelles,
tout ce qu'elle demandait par l'utilisateur,
mais il y a des données potentiellement que vous pouvez garder,
voilà, et notamment sur des trucs pas du tout critiques.
Pourquoi est-ce que c'est facile en plus de faire du soft delete ?
C'est que la majorité des connecteurs en base de données,
que ce soit SQL ou NoSQL,
ils proposent une option pour faire du soft delete.
Donc dès que vous allez utiliser la commande ou la méthode pour supprimer une donnée,
eh bien il va déjà avoir potentiellement prévu le champ pour supprimer,
pour faire du soft delete,
et en plus il va simplement passer ce champ là à trou,
quand vous allez utiliser la commande delete classique,
donc vous allez même pas forcément avoir besoin de logiques supplémentaires dans votre code,
évidemment ça dépend, ça va vraiment dépendre du connecteur,
des fois ça va simplement être un plugin à rajouter, etc.
Mais en tout cas c'est quelque chose,
il faut savoir que ça existe,
il faut savoir là je vous ai donné l'utilisateur en exemple,
l'utilisateur c'est vraiment pas forcément le meilleur meilleur exemple,
mais vous pouvez trouver plein plein de cas d'utilisation de ce soft delete,
et qui est vraiment utilisé parce que c'est vraiment très pratique,
à savoir aussi que souvent en base de données,
quand vous avez des suppressions en chaîne comme ça,
des grosses transactions pour la suppression de données,
eh bien en fait c'est ce qui va coûter énormément énormément énormément de,
comment dire en puissance de calcul à la base de données,
donc si vous avez beaucoup de suppression en même temps,
ça peut potentiellement surcharger votre serveur,
le soft delete est moins gourmand parce qu'on va modifier qu'une seule donnée,
et non pas on modifié 15 000,
et donc tout simplement ça va permettre de lisser un petit peu ces performances,
donc voilà c'est vraiment pas quelque chose à négliger,
vous perdez un petit peu d'espace de stockage,
mais souvent l'espace de stockage en réalité,
sur une base de données,
c'est vraiment ce qu'on va pouvoir sacrifier au maximum,
plutôt que la performance.
Voilà j'espère que cet épisode vous aura plu,
et vous aura été utile,
et moi je vous donne rendez-vous sur code garage bien évidemment,
et à la semaine prochaine pour un prochain épisode, salut !