[Optimisation] Operation sur tous les tuples [Résolu]

[agougeon]

Bonjour,

J'aimerai savoir si ma méthode est bonne, elle marche mais je sais pas si c'est la meilleurs,

Voila, j'ai une requete qui me retourne une liste de numéro : NUM
et je dois effectuer des opérations sur tous ces numéros.
J'ai donc fais une table temporaire qui contient tous les numéros et je boucle dessus selon l'algo :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
NOMBRE_OPERATION = SELECT count(*) tempTable
while @NOMBRE_OPERATION != 0
begin
-- Je recupere un numero
	SET rowcount 1
	SELECT @NUM = NUM FROM tempTable	
	SET rowcount 0
 
-- Traitement....
 
-- Fin de traitement, je decremente le compteur et je supprime la ligne qui viens d'etre traité
DELETE FROM tempTable WHERE NUM=@NUM	
SELECT @NOMBRE_OPERATION = @NOMBRE_OPERATION - 1
end

Merci

PS : C'est pour eviter les curseurs

[mpeppler]

On cherche à éviter les curseurs en ecrivant l'opération sous une forme ensembliste, et de laisser l'optimiseur du SGBD trouver le meilleur chemin pour exécuter l'opération.

Si un processing itératif est requis alors un curseur est probablement équivalent (ou peut-être un peu plus efficace) qu'une boucle du style

Code :

1
2
3
4
5
6
 
while @id > 0
begin 
.........
    SELECT @id = min(id) FROM temptable
end

J'ai vu des problèmes de locks avec les curseurs en 11.9.2 il y 7 ou 8 ans (un curseur READ ONLY ne relachait pas les verrous sur certaines tables), mais en 12.x ou en 15 il ne devrait pas y avoir de problème de ce genre. Il n'y a donc pas de raison de ne pas les utiliser si un processing itératif est inévitable (l'ecriture de l'opération sous forme ensembliste étant à priori à favoriser).

Michael

[agougeon]

Ok, alors j'effectue bien le bon process?
As tu oublié de supprimer le champ dans ton code? ou ce n'est pas la peine (je pense que oui, sinon tu aura toujours le meme id ^^)

Code :

1
2
3
 
DELETE FROM temptable WHERE id=@id
SELECT @id = min(id) FROM temptable

Merci

[mpeppler]

Ton code est correcte. Mon code n'était là que pour faire l'illustration (et est effectivement incorrecte !)

Michael