Discussion :

[DOliv]

Bonjour à tous.tes,
J'ai mis ce titre là parce que je ne savais pas quoi mettre d'autre.
En fait je me demande ce qui peut faire que l'exécution d'une procédure stockée devienne de plus en plus lente en cours d'exécution.

Elle met en oeuvre un cursor qui boucle dans un deuxième.

En clair, ou pas, le premier boucle sur un SELECT de lignes d'entête.
Chaque ligne de ce premier cursor sert de clé au deuxième cursor qui SELECT un ensemble de lignes liées par ID à l'entête.
Un nouvel ID est affecté à l'enreg du premier CURSOR et est donc UPDATé dans tous les enreg du deuxième cursor, qui sont ensuite INSERTés dans une table. Puis l'enreg du premier cursor est INSERTé dans une autre table.
Ni plus ni moins qu'un système d'historisation.

Le premier boucle sur plusieurs dizaines de milliers de lignes, et le deuxième sur plusieurs centaines de milliers de lignes.

Donc, c'est long. Mais mon questionnement concerne le fait que, au fur et mesure du traitement, celui-ci est de plus en plus long.
En effet, le nombre de lignes "détail" par ligne "principales" est en moyenne le même. Le traitement des premiers enregs sont très rapide, et les derniers sont beaucoup plus lents, et de plus en plus lents pendant le traitement.
D'où ma question :
Ne serait-il pas possible de faire une opération quelconque, par exemple après chaque INSERT, pour maintenir le même niveau de performance tout au long du traitement ?
Est ce nécessaire de préciser le SGBD ? Ou le problème, comme je le pense, est inhérent à tous les SGBD.

Merci d'avance pour vos observations et, au-moins, d'avoir lu jusqu'au bout

[tatayo]

Bonjour,
Sans connaitre ni le code, ni la description des tables, ni le SGBD concerné, difficile de répondre.

Mais j'ai tout de même nue question: plutôt que d'utiliser 2 curseurs imbriqués, n'est-il pas possible d'utiliser des requêtes de type INSERT INTO ... SELECT ?
Je pense que ce serait bien plus rapide, surtout s'il faut traiter plusieurs milliers de lignes.

Tatayo.

[DOliv]

Bonjour,
Sans connaitre ni le code, ni la description des tables, ni le SGBD concerné, difficile de répondre.

Mais j'ai tout de même nue question: plutôt que d'utiliser 2 curseurs imbriqués, n'est-il pas possible d'utiliser des requêtes de type INSERT INTO ... SELECT ?
Je pense que ce serait bien plus rapide, surtout s'il faut traiter plusieurs milliers de lignes.

Tatayo.

Oui mais là, ce n'est pas possible de faire la même chose avec un INSERT INTO ... SELECT.

[SQLpro]

...
En fait je me demande ce qui peut faire que l'exécution d'une procédure stockée devienne de plus en plus lente en cours d'exécution.

Elle met en oeuvre un cursor qui boucle dans un deuxième.

Vous êtes en train de faire de la programmation spaghetti (itérations avec des boucles dans tous les sens) alors qu'un SGBD Relationnel est fait pour exécuter très rapidement (grâce aux index, au parallélisme et à l'optimiseur) des requêtes ensemblistes !

Dès lors le comportement de votre code sera strictement linéaire et va devenir de plus en plus lent à la charge...

En clair, ou pas, le premier boucle sur un SELECT de lignes d'entête.
Chaque ligne de ce premier cursor sert de clé au deuxième cursor qui SELECT un ensemble de lignes liées par ID à l'entête.
Un nouvel ID est affecté à l'enreg du premier CURSOR et est donc UPDATé dans tous les enreg du deuxième cursor, qui sont ensuite INSERTés dans une table. Puis l'enreg du premier cursor est INSERTé dans une autre table.

NOTE importante : dans un SGBDR le terme "enregistrement" n'a pas sa place. On parle de lignes (rows).
A lire : https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2

Vous êtes typiquement dans le piège RBAR... Row By Agonizing Row... À lire :
https://www.red-gate.com/simple-talk...agonizing-row/

Ni plus ni moins qu'un système d'historisation.

Le premier boucle sur plusieurs dizaines de milliers de lignes, et le deuxième sur plusieurs centaines de milliers de lignes.

Donc, c'est long. Mais mon questionnement concerne le fait que, au fur et mesure du traitement, celui-ci est de plus en plus long.

Chaque fois que vous exécutez une requête les données sont mise en cache. Une requête elle même se compose de plusieurs phases d'exécution dont certaines parties peuvent comporter des dizaines d'appel à des tables système... Plus vous avancez dans vos boucles, plus il y aura besoin de mémoire et plus cela deviendra lent....

En effet, le nombre de lignes "détail" par ligne "principales" est en moyenne le même. Le traitement des premiers enregs sont très rapide, et les derniers sont beaucoup plus lents, et de plus en plus lents pendant le traitement.

Tout à fait symptomatique du RBAR...

D'où ma question :
Ne serait-il pas possible de faire une opération quelconque, par exemple après chaque INSERT, pour maintenir le même niveau de performance tout au long du traitement ?
Est ce nécessaire de préciser le SGBD ? Ou le problème, comme je le pense, est inhérent à tous les SGBD.

NON !!!

Il faut tout simplement faire une seule requête de tout votre traitement....

Postez votre code que l'on vous aide !

A +

PS : certains SGBDR, comme Microsoft SQL Server, sont dotés d'une historisation automatique des lignes des tables. À lire :
https://blog.developpez.com/sqlpro/p...r-presentation

[DOliv]

Intéressant. Je vais déjà lire tout ça et repenser ma copie. Merci à tous.

[DOliv]

Mouai... En fait, j'ai beau fouiller toutes les techniques SQL, même avec des CTE à foison, je ne vois pas bien comment il pourrait être possible de sélecter un ensemble de données issu de deux tables différentes, dont les lignes sont liées par un ID.
Modifier la valeur des IDs de liaison des lignes d'entête ET, évidemment des lignes de détail liées.
INSERTé le résultat dans deux nouvelles tables.
Le Tout dans une seule requête

Alors je pense à un script SQL, peut-être. Mais pourquoi un script SQL serait-il plus rapide qu'une procédure stockée ?

[tatayo]

Pourquoi avec une seule requête ?
Tu peux faire l'historisation avec 2 requêtes, une pour les entêtes et une pour les lignes.
J'imagine bien qu'il y a un "lien" entre la table des entête et son pendant "historisé".
Donc ça va donner un truc du genre:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
-- On commence par historiser les entêtes
insert into histo_ent(col1,col2,col3...)
select col1,col2,col3,...
from ent
where ...
 
- Ensuite on historise les lignes correspondantes
insert into histo_lig(idHistoEnt,colx,coly,col7,...)
select histo_ent.ident,colx,coly,colz...
from histo_ent
inner join ent on ent.id = histo_ent.idEnt
inner join lig on lig.idEnt = ent.idEnt
left outer join histo_lig on histo_lig.idHistoEnt = histo_ent.Id
where ... -- Les même critères que ci-dessus
and histo_lig.id is null -- On peut aussi tester l'absence de ligne, pour plus de sécurité

En choisissant le bon niveau d'isolation bien sûr (serializable ?).
C'est écrit "un peu à la va vite", mais l'idée est là.

Tatayo.

[DOliv]

Merci Tatayo,
mais une fois les entêtes INSERTés avec le nouvel ID tu ne connais plus le lien avec leurs lignes détail qui contiennent toujours l'ancien ID.
Sauf erreur de ma part, la seule solution est de updater le nouvel ID affecté à un entête, à chacune des lignes détails de cet entête, avant de passer à l'entête suivant. Sinon le lien est brisé