Discussion :

[Lafoudre]

Bonjour à tous,
Tout d'abord je dois préciser que mon niveau SQL est tres faible...

voilà mon problème :

j'ai une procédure stockée qui parcours une table tres volumineuse et dans la close where du select de cette procedure, j'utilise le résultat d'une fonction.

Cela fonctionnait bien jusque maintenant mais on doit maintenant modifirer la fonction.
Le problème est que cette modification implique de parcourir une table assez volumiseuse aussi.

Donc je me retrouve à parcourir une premiere table tres volumineuse et pour chaque élément de cette table, je dois parcourir une autre table volumineuse.
Donc en gros si la première table contient 10000 lignes, je parcourerai 10000 fois la seconde table ... Qui elle meme peut contenir le meme nombre de ligne ...

Le but de passer la seconde table comme paramètre à la fonction, sous forme de curseur, serait de la charger une seule fois en mémoire afin de gagner en rapidité d'exécution

Est ce que c'est possible ?
La solution du curseur est elle la meilleure d'un point de vue performance ?

Merci d'avance pour votre aide

[SQLpro]

non, cela n'est pas possible.

en revanche je m'étonne que vous ayez besoi de tout se fatras. Une simpel requête avec une sous requête corrélée doit faire l'affaire.

commencez donc pas apprendre le SQL, parce que si vous commencez par imbriquer des appels de procédure sur des curseur de curseur de curseur, votre applications sera un veau !

En principe depuis SQL Server 2005, tout traitement aussi complexe qu'il soit doit pouvoir être écrit en une seule requête.

A +

[Fabien Celaia]

En principe depuis SQL Server 2005, tout traitement aussi complexe qu'il soit doit pouvoir être écrit en une seule requête.

"I had a dream..."
Martin Luther King

[Lafoudre]

Bon vous aviez raison, on peut résoudre cela par un subselect, le tout est de savoir si ma première table fait 5000 lignes et ma seconde en fait autant ca me fait 5000X5000 tests à faire ce qui peut etre un peu lourd. D'autant que le retour de la procédure est lui aussi traité par la suite.

Enfin je me suis arrangé pour faire passer un des select en code C# et pour ne le lire que quand c'est vraiment utile et le stocker une seule fois en mémore dans un dataset ce qui a l'air de fonctionner plus rapidement que le subselect.

[SQLpro]

Une requête sera généralement toujours plus efficace qu'un curseur à de très rares exceptions près....

De plus rien ne vous interdit d'imbriquer les requêtes les unes dans les autres ce qui sea aussi plus efficace que de les enchainées dans des tables temporaires :

SELECT ..
FROM ( SELECT ... )
)

A +