Discussion :

[scamphp]

Bonjour, toujours dans mes recherches pour comprendre le fonctionnement d'une base de donnée, je me pose une nouvelle question.

Quand on fait un delete cela supprime une ligne. Jusque là pas de problème pour l'utilisateur.

Mais c'est quoi l'impact "physique" sur la bdd. Cette ligne vide devient quoi ? -> rien tout va bien OU un vide ce qui transforme la bdd en gruyère.

Avec delete on supprime des ligne mais cela n'a pas d'impact (tout remonte d'un cran sauf id auto-incrément).

Ou cela fragmente la table un peu comme des fichiers sur un disque dur (avec des vides qui ralentissent les recherches).

[Artemus24]

Salut scamphp.

Mais c'est quoi l'impact "physique" sur la bdd. Cette ligne vide devient quoi ? -> rien tout va bien OU un vide ce qui transforme la bdd en gruyère.

Une erreur que tout le monde fait, le gruyère, qui est suisse, n'a pas de trous. Tandis que l'emmental, qui est français, en a !
--> https://www.yapaslefeuaulac.ch/le-gr...-pas-de-trous/

Oui, vous avez raison, après suppression de lignes dans une table, il y a des trous.

Avec delete on supprime des ligne mais cela n'a pas d'impact (tout remonte d'un cran sauf id auto-incrément).

Imaginez qu'avec tous vos trous, il y a une ligne par page.
Et bien, il faudrait lire physiquement toutes ces pages, ce qui prendrait plus de temps que si toutes ces lignes étaient dans la même page.

Ou cela fragmente la table un peu comme des fichiers sur un disque dur (avec des vides qui ralentissent les recherches).

La recherche prend plus de temps car vous êtes obligés de faire plus de lecture physique.

C'est pourquoi, il y a deux philosophies, à savoir :
--> ne jamais rien supprimer ou si vous préférez, on utilise une colonne pour indiquer si la ligne est active ou pas.
--> ou bien, effectuer physiquement la suppression, en faisant régulièrement une réorganisation de votre table.

@+

[Christophe]

Mais c'est quoi l'impact "physique" sur la bdd. Cette ligne vide devient quoi ?

L'espace est réaffecté à un prochain enregistrement, et les éventuels index sur les données supprimées sont mis à jour.

[escartefigue]

Une erreur que tout le monde fait, le gruyère, qui est suisse, n'a pas de trous. Tandis que l'emmental, qui est français, en a !
--> https://www.yapaslefeuaulac.ch/le-gr...-pas-de-trous/

Ca aussi c'est une erreur que beaucoup de monde fait
Le gruyère n'est pas seulement suisse, mais également français
Et il a des trous, certes, bien plus petits que ceux de l'emmental, mais des trous quand même
cf. https://www.entremont.com/fr/actuali...re-et-emmental

Ce qui est important c'est que
- pendant l'opération de suppression, les page data et les pages index sont impactées, donc plus il y a d'index, plus l'opération est couteuse
- via les contraintes d'intégrité de type référence, tous les index des tables dépendantes pour la FK sont également impactés. Si la clause DELETE CASCADE a été positionnée, cela peut prendre un temps considérable si les volumes dans les tables sont énormes (plusieurs milliards de lignes) et/ou que la cascade de dépendances est d'une profondeur importante (via l'identification relative par exemple). C'est pourquoi on délègue souvent les suppression physiques (ordres DELETE) à des batchs planifiés en périodes creuses. Les autres traitements positionnent un indicateur de suppression logique, et le traitement batch spécifique ramasse ensuite tous les enregistrements concernés pour faire la suppression physique.

[scamphp]

La recherche prend plus de temps car vous êtes obligés de faire plus de lecture physique.

--> ne jamais rien supprimer ou si vous préférez, on utilise une colonne pour indiquer si la ligne est active ou pas.

Est-ce que la solution de ne pas supprimer les lignes mais de les réutiliser est une bonne solution.

Style je veux supprimer mon article 124 -> je vide la ligne et je mets un champ "ne pas publier"

et quand je crée mon nouvel plutôt que d'ajouter une nouvelle ligne article 523 -> je réutilise la ligne de l'article 124 pour l'enregistrement (modifie plutôt que delete) et je passe le status en "publier"

Modifier des anciennes lignes plutôt que de les supprimer c'est bien ou cela génère d'autres problèmes du style une modification change la taille des enregistrements -> ancien contenu 450 caractère, nouveau contenu 640 caractère

Création d'un gruyère non plus au niveau des lignes mais des colonnes...

[escartefigue]

Est-ce que la solution de ne pas supprimer les lignes mais de les réutiliser est une bonne solution.

Style je veux supprimer mon article 124 -> je vide la ligne et je mets un champ "ne pas publier"

Surtout pas
"Vider une ligne", ça n'existe pas, s'il s'agit de faire une mise à jour pour remplacer les valeurs présentes par des blancs ou zéro, ce serai techniquement sans intérêt et fonctionnellement aberrant

Modifier des anciennes lignes plutôt que de les supprimer c'est bien ou cela génère d'autres problèmes du style une modification change la taille des enregistrements -> ancien contenu 450 caractère, nouveau contenu 640 caractère

Excellente question et la réponse est oui : l'impact peut être très conséquent, quand la nouvelle taille de la ligne augmente, cela peut provoquer des déplacements de pages data et index, qui ralentissent le traitement, à éviter

Oubliez les solutions abracadabrantes !
Soit votre suppression concerne peu de lignes en tenant compte des contraintes de type référence, auquel cas un delete est possible, soit c'est le contraire et en ce cas un marquage logique est préférable (update d'un flag d'annulation)

Il faut voir aussi si le DELETE est souhaitable, on préfère souvent marquer logiquement une ligne à "annulée" pour en garder une trace
Attention aussi aux contraintes réglementaires sur la durée de conservation

[scamphp]

Si je comprend bien

Quand Artemus24 dit -->

ne jamais rien supprimer ou si vous préférez, on utilise une colonne pour indiquer si la ligne est active ou pas.

ce n'est pas dans l'idée de réutiliser la ligne ?

[Artemus24]

Salut Scamphp.

Est-ce que la solution de ne pas supprimer les lignes mais de les réutiliser est une bonne solution.

Il ne faut surtout pas faire cela. Une ligne peut appartenir à une grappe de données au travers des clefs étrangères.
Supprimer la ligne revient à créer un problème d'intégrité.

Modifier des anciennes lignes plutôt que de les supprimer c'est bien ou cela génère d'autres problèmes ...

La suppression ne concerne pas qu'un simple problème de volumétrie ou d'intégrité.
Dans le cadre bancaire, il existe des contrôle fiscaux qui font que nous devons conserver l'intégralité de la base de données sur dix ans.
De ce fait, on ne peut pas faire de suppression physique, mais des suppressions logiques, sans alétérer le contenu de ces données.

De plus, on peut très bien extraire ces lignes supprimées pour les mettre en archives, ce qui permet encore de les consulter, même si elles ne sont plus traitable.

Attention aussi aux contraintes réglementaires sur la durée de conservation

Entre autre, la fiscalité à cause des contrôles, dont la durée est de dix ans en entreprise et cinq ans pour des particuliers.

ce n'est pas dans l'idée de réutiliser la ligne ?

C'est pour garder une trace de ce que vous avez fait, au paravant dans votre base.
On nomme cela historiser vos données, ce qui implique de savoir gérer le temps dans votre base de données.

Cela veut dire qu'à l'usage au fil des mois et des modifications le site va ralentir ?

Quel est l'intérêt de faire une suppression ? C'est ce genre de question que vous devez vous poser.

Si au cours du temps, une ligne dans une table peut évoluer, et que le temps à justement de l'importance, alors vous devez annuler l'ancienne ligne et créer une nouvelle ligne.
Ne pas oublier que l'on peut vous demander de faire un état de votre base de données à une date d'arrêter.
Comment feriez-vous si vous supprimez physiquement vos lignes ?

@+

[scamphp]

Dans le cadre financier et comptable je comprend l’intérêt de conserver un historique.

Mais dans le cadre d'un blog avec des articles qui peuvent être mis à jour tous les 6 mois, la fonction modifier... je rajoute un peu de texte... puis sur un autre article je supprime un paragraphe qui n'est plus d'actualité....

Il n'y a aucun intérêt à conserver un historique, ni besoin de ressortir un article de telle ou telle époque.

Le fait de modifier ses articles a-t-il un impact conséquent -> quand la nouvelle taille de la ligne augmente, cela peut provoquer des déplacements de pages data et index, qui ralentissent le traitement, à éviter ???

[escartefigue]

Dans le cadre financier et comptable je comprend l’intérêt de conserver un historique.

Mais dans le cadre d'un blog avec des articles qui peuvent être mis à jour tous les 6 mois, la fonction modifier... je rajoute un peu de texte... puis sur un autre article je supprime un paragraphe qui n'est plus d'actualité....

Il n'y a aucun intérêt à conserver un historique, ni besoin de ressortir un article de telle ou telle époque.

Dans tous les cas, les règles de conservation sont à faire valider par vos donneurs d'ordre, c'est eux qui fixent les règles métier, s'ils confirment qu'il n'y a pas de durée minimale de conservation, alors vous pouvez effectivement supprimer les lignes (DELETE donc). Mais il vous reste à vérifier quand faire ces suppression, soit au fil de l'eau, soit en périodes creuses, voir ma réponse précédente sur la stratégie de DELETE

Le fait de modifier ses articles a-t-il un impact conséquent -> quand la nouvelle taille de la ligne augmente, cela peut provoquer des déplacements de pages data et index, qui ralentissent le traitement, à éviter ???

Oui, c'est ce que j'ai écrit plus haut, à éviter
Mais à considérer quand on fait des mises à jour (rien à voir avec la suppression). Si la probabilité de modification à la hausse de la longueur totale est forte, alors le risque est élevé. C'est l'un des inconvénients du type varchar

[Artemus24]

Salut Scamphp.

Mais dans le cadre d'un blog ...

Justement, que voulez-vous supprimer dans un blog ?
Par exemple, Les billets les plus anciens, disons ceux de plus de 1 ans.
Dans ce cas, cela ne doit pas se faire au fil de l'eau, mais ponctuellement, par un script qui va supprimer ces lignes et réorganiser vos tables.
En réorganisant vos tables, vous bouchez les trous, et rendez celles-ci plus performantes.

@+