boucle sur 'SELECT *'

**castasql** · 10/01/2007, 15h48

Bonjour,

je crée des fichiers .sql de maniere a créer des procedure stockées.

Dans une de mes procedures stockée, je souhaiterai parcourir toute une table (table_filtre aves les colonnes test1 et test2) et ensuite faire un traitement pour chaque enregistrement...

j'ai travaillai avec postgre et la requete etait du type:
FOR _resultat IN (SELECT * FROM table_filtre) LOOP
IF(_resultat.test1='toto') THEN
[...traitement...]
END IF;
END LOOP;

existe t-il sous MySQL un moyen de faire la meme chose en procedure stockée??
j'ai vu qu'il existe des boucle WHILE, mais comment fait on pour recuperer les enregistrements un à un???

j'espere avoir été assez clair...

Merci

**Antoun** · 10/01/2007, 20h44

Envoyé par castasql

Dans une de mes procedures stockée, je souhaiterai parcourir toute une table (table_filtre aves les colonnes test1 et test2) et ensuite faire un traitement pour chaque enregistrement...

c'est beaucoup plus lent que de le faire en bloc...

Envoyé par castasql

existe t-il sous MySQL un moyen de faire la meme chose en procedure stockée??
j'ai vu qu'il existe des boucle WHILE, mais comment fait on pour recuperer les enregistrements un à un???

Avec un curseur http://dev.mysql.com/doc/refman/5.0/fr/cursors.html mais c'est MAL

http://sqlpro.developpez.com/cours/s...r_avoidCursor/

(c'est ma journée "SQLpro contre les curseurs"

)

**castasql** · 11/01/2007, 12h04

eviter les curseurs... est ce vraiment instable? est ce vraiment gourmand???

car pour effectuer le traitement que j'ai a faire, la seule méthode alternative serait la methode 3 du lien que tu m'as donnée... avec une table temporaire....
http://sqlpro.developpez.com/cours/s...r_avoidCursor/

hors elle me semble tres lourde, et ressemble plus a une bidouille qu'a une vrai solution...

en fait je voudrai savoir si ce curseurs cont vraiment instable? et qu'est ce que tu entend pas gourmand??

**Antoun** · 11/01/2007, 18h38

Envoyé par castasql

car pour effectuer le traitement que j'ai a faire, la seule méthode alternative serait la methode 3 du lien que tu m'as donnée... avec une table temporaire....

hors elle me semble tres lourde, et ressemble plus a une bidouille qu'a une vrai solution...

c'est surtout une bidouille propre à SQL Server !

Envoyé par castasql

en fait je voudrai savoir si ce curseurs cont vraiment instable? et qu'est ce que tu entend pas gourmand??

Ce que Fred entend par "gourmand", c'est que les SGBD sont optimisés pour faire du traitement en masse (dit "ensembliste"). Avec un curseur, tu les forces à travailler ligne par ligne... c'est comme si tu avais une Ferrari et que tu ne roulais qu'en première.

Je doute bcp que l'exemple 3 de Fred, qui est un script de pure administration de BDD, soit la seule solution. En quoi consiste ton "traitement" ? (si c'est vraiment de l'admin,
je te dirais peut-être de faire un curseur

)

**castasql** · 11/01/2007, 19h12

je pense que je suis vraiment obligé d'utiliser un CURSEUR, mais je vais suivre ton conseil en évitant au maximum...

j'aurai une autre question

la taille est la complexité de mes procedure stockée grandit a vue d'oeil, même si j'essaie au maximum de les découper en petite procedures...
Je voudrai donc savoir s'il existait un "pré-compilateur" ou "verificateur de syntaxe" un minimum puissant, permettant surtout d'isoler les problemes plus préceisement...
car lorsque on ajoute un procedure stocké avec la commande:
"/usr/local/mysql/bin/mysql < maprocedure.sql" le detail de l'erreur est assez limité et tres vague...

j'accepte les outils pour windows comme pour linux

merci