delete pour supprimer

Version imprimable

02/06/2018, 09h24
scamphp

delete pour supprimer

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).
03/06/2018, 10h52
Artemus24

Salut scamphp.

Citation:

Envoyé par 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.

Citation:

Envoyé par Scamphp

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.

Citation:

Envoyé par Scamphp

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.

@+
04/06/2018, 09h04
Christophe

Citation:

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.
04/06/2018, 09h08
escartefigue

Citation:

Envoyé par Artemus24

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 :P
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.
04/06/2018, 10h17
scamphp

Citation:

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...
04/06/2018, 11h11
escartefigue

Citation:

Envoyé par scamphp

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

Citation:

Envoyé par scamphp

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
04/06/2018, 13h20
scamphp

Si je comprend bien

Quand Artemus24 dit -->

Citation:

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 ?
04/06/2018, 13h47
escartefigue

Vous confondez l'usage logique d'une ligne et l'accès physique aux données, et parler de réutilisation est équivoque

Au niveau logique, vous pouvez utiliser un attribut mettons "STATUT_LIGNE" qui prend plusieurs valeurs parmi lesquelles une valeur particulière signifiant que la ligne est "supprimée logiquement", c'est à dire qu'il ne faut pas en tenir compte. Mais physiquement, cette ligne est bien présente dans la base de données. La distinction entre ligne active et ligne supprimée logiquement est réalisée soit par l'application, soit via des vues qui vont filtrer sur les valeurs de STATUT_LIGNE qui vont bien.

Au niveau physique, la réutilisation des emplacements après une suppression , c'est à dire après un ordre DELETE, n'a pas d'importance au niveau métier, c'est le moteur le la base de données et les utilitaires qui permettent de réagencer dans un ordre optimal et réutiliser physiquement les espaces libérés.
04/06/2018, 14h43
scamphp

Ok super merci pour vos réponses.... pour delete maintenant c'est clair...

Par contre, quand au fil du temps si je modifie mes articles se pose donc un d'autre problème.

Citation:

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

Cela veut dire qu'à l'usage au fil des mois et des modifications le site va ralentir ?
04/06/2018, 15h05
Artemus24

Salut Scamphp.

Citation:

Envoyé par 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é.

Citation:

Envoyé par Scamphp

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.

Citation:

Envoyé par Escartefigue

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.

Citation:

Envoyé par Scamphp

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.

Citation:

Envoyé par Scamphp

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 ?

@+
04/06/2018, 15h52
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 ???
04/06/2018, 16h19
escartefigue

Citation:

Envoyé par 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.

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

Citation:

Envoyé par scamphp

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
04/06/2018, 17h37
Artemus24

Salut Scamphp.

Citation:

Envoyé par 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.

@+