Discussion :

[JeanYvette]

Bonjour bonjour,

Petite demande qui va amener à deux questions, potentiellement bête, mais sûr laquelle je n'arrive pas à trouver de certitude.
Voila mon petit soucis :

Un script sql de 3 000 lignes avec une boucle de curseur principale qui appelle d'autres curseurs, fait tout plein d'opérations youpi tralala...
Dans cette boucle, après l'appel de 4-5 curseur, il y a une insertion dans une table.

Ceci amène à ma première question : Vaut-il mieux, dans le cas d'une loop sur des milliers de lignes, faire un insert de suite, ou écrire les lignes dans un fichier pour ensuite faire un sqlload dessus ? Je sais que le sql load est plus rapide que l'insert, mais après, c'est par rapport à l'écriture du fichier où je ne suis pas sûr que le gain de temps se fasse remarquer...


Dans ce script aussi, il y a pas mal de if sur des données du curseur amenant la boucle principal. Des if du style :

Code :

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

If (moncurseur.data = 0) THEN moncurseur.data = 'CC' ELSE moncurseur.data = 'VV'

Je ne sais pas si c'est propre à moi, mais ca me défrise un peu, je serais potentiellement passé par des clause CASE ou DECODE de suite dans le select plutôt que par des if dans le curseur.

Ma deuxième question est donc : if vs case ? Quel serait le plus rapide (si bien sûr il y a un plus rapide)

Pour info : Le script est donc un fichier .sql appelé avec sqlplus sous linux

Merci d'avance

Bisous bisous

[Michel.Priori]

Bonjour,

Les curseurs, c'est le mal.

Les développeurs vont dire que c'est plus lisible que du code SQL ; la preuve.

Si possible revenir à l'expression du besoin (la doc ??) et recoder ça avec un INSERT ... SELECT ...

Pour répondre à la question :
Solution 1 : remplir ligne à ligne un fichier externe à la base, et, quand le traitement est fini reverser les lignes du fichier dans la base
Solution 2 : remplir la table ligne à ligne avec
(S2.1) une transaction sur l'ensemble des lignes
(S2.2) une transaction par insert

La S1 est pour moi la pire :
-le périmètre de sécurité est élargi
-la gestion des erreurs est élargie (place sur disque, droits, suppression sauvage pendant le traitement, ...)

Du coup la S2 est moins pire mais se pose la question des transactions et de l'isolation des traitements.
-Que se passe t'il si la procédure est lancée plusieurs fois alors que la première exécution n'est pas finie ?
-Coté rollback segment la S2.2 est meilleure mais exige un "scénario de reprise" (dans ce cas, je pense qu'il est plutôt simple : relancer la procédure)
-Coté perf pure la fréquence des COMMIT est en soit une conversation
.trop fréquent = logwriter en continu
.trop peu fréquent = des redo actifs trop longtemps
Bref entre les 2 mon coeur balance.

[al1_24]

Vérifie si ton script ne pourrait pas tout simplement se transformer en un simple INSERT ... SELECT

Me souviens avoir repris ainsi quelques scripts PL/SQL qui paraissaient bien complexes avec curseurs imbriqués, tests multiples, compteurs incrémentés à chaque passage, etc et qui se sont simplifiés en une seule requête et un gain de temps de traitement de plusieurs heures.
Le développeur original n'avait en fait rien compris au SQL et traitait les tables comme des fichiers indexés dans un langage procédural classique.

[JeanYvette]

Bonjour à tous et merci pour vos réponses.
En effet les curseurs, c'est mal, surtout que là, une fois sur deux la personne passe par un curseur avec paramètres, les autres fois par des fonctions... et parfois les deux sont aussi "viables" les uns que les autres...

Alors pour répondre aux questions :

Sur le périmètre de sécurité et gestions des erreurs sur l'écriture de fichier : 75% des scripts existants passent par écriture de fichiers donc la gestion de la place, des droits, tout ça, y'a pas de soucis.
Ensuite, les scripts sont lancés par un ordonnanceur donc si il y a un plantage, c'est tout qui est rollback, le script ne se relancera pas à nouveau et surtout il n'est pas possible que le script tourne plusieurs fois en même temps.

Je sais que au niveau des questions j'étais plus dans la micro optimisation mais c'est ce qui semblait le plus rapide à faire.. Pour le fait de passer pas des select....insert, je suis totalement d'accord, il faudra que je regarde, car il y a en effet tellement de curseurs, fonctions, vérifications ect que ca va être drôle à refaire...

En tout cas merci pour vos avis

[McM]

Les curseurs sont beaucoup plus rapide que d'écrire un fichier sur le serveur et de le recharger avec sqlloader (ou table externe)

Dire que les curseurs c'est le mal, je ne suis pas d'accord, ça reste de l'algorithmie.
C'est sur que si les curseurs peuvent être remplacés par un INSERT SELECT .. c'est juste un mauvais développement.

Les VUES c'est le mal !!

[Michel.Priori]

Bonjour,

Dire que les curseurs c'est le mal, je ne suis pas d'accord, ça reste de l'algorithmie.

C'est exactement la même position que dire que

Code :

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

SELECT *

ça peut être bien, mais faut l'utiliser dans des cas précis.
Dans les faits, le nombre de personnes qui accèdent effectivement à la subtilité sont soit des relecteurs soit des génies car la réalité est que le développeur, payé au mois, doit produire son code pour hier sachant que le cahier des charges arrivera demain.

L'utilisation de curseurs revient à utiliser une logique :
1- de langage de 3ieme génération (description du process)
2- de traitement ligne à ligne
Or le langage SQL ne répond à aucun de ces 2 caractéristiques.
Produire du code interprété dans un environnement spécialisé sans respecter les caractéristiques de base, je ne vois pas en quoi ça peut être autre chose que mal.

Et je suis tout à fait d'accord pour dire que les VUES, utilisées pour de l'encapsulation/réutilisation de code c'est aller, encore une fois, à l'encontre du langage SQL.
Donc oui, les VUES et les CURSEURS sont les outils de la tentation du diable : le mal.

Ps: je crois que je vire spirituel moi là

[McM]

L'utilisation de curseurs revient à utiliser une logique :
1- de langage de 3ieme génération (description du process)
2- de traitement ligne à ligne
Or le langage SQL ne répond à aucun de ces 2 caractéristiques.
Produire du code interprété dans un environnement spécialisé sans respecter les caractéristiques de base, je ne vois pas en quoi ça peut être autre chose que mal

On n'est pas en SQL, mais en PL/SQL
A partir du moment où je suis en plsql, c'est que j'ai généralement besoin faire du traitement par ligne => curseur.
Le cas où je n'ai pas besoin de curseur est plutôt marginal (ou alors ce sont des fonctions simples).

[Michel.Priori]

Bonjour,

C'est sur que si les curseurs peuvent être remplacés par un INSERT SELECT .. c'est juste un mauvais développement.

Le cas où je n'ai pas besoin de curseur est plutôt marginal

C'est moi ou c'est incohérent ?

A mais non, faut tout lire :

A partir du moment où je suis en plsql, c'est que j'ai généralement besoin faire du traitement par ligne

Je pense que la phrase est mal formulée et que le sens voulu est:

A partir du moment où j'ai besoin de faire du traitement par ligne, c'est que j'ai généralement besoin faire du plsql

Et là ça change tout.

Mais au fait, c'est quand qu'on a "besoin de faire du traitement par ligne" dans un SGBD ?
(pour moi il y a 1 réponse, mais voyons les propositions)