Discussion :

[dens19]

Bonjour à tous,

Je crée une table temporaire qui va contenir tout un tas d'indicateurs. Je réalise d'abord un INSERT INTO pour créé les lignes de ma table et ensuite je réalise différents UPDATE ... SET ... FROM pour mettre à jour les différentes colonnes de ma table comme ci-dessous :

Code :

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
17
 
UPDATE	@ReturnTable
SET	    Bon = Qte
FROM    (SELECT	TEMP.Nom AS [RESULT_Nom], COUNT(DISTINCT TEMP.Numero) AS [Qte],  TEMP.FluxID AS [RESULT_FluxID], P.NumeroBadge
	     FROM	@table_temporaire AS TEMP
			INNER JOIN PASSAGES P WITH (nolock) ON P.Numero = TEMP.Numero AND P.NumeroBadge = TEMP.NumeroBadge AND P.ResultatControle = 1 AND DateHeure > @todayDate  
   	   GROUP BY	TEMP.Nom, TEMP.FluxID, P.NumeroBadge) AS [RESULT]
WHERE Operateur = RESULT_Nom AND FluxID = RESULT_FluxID
 
/********************************************************/			
UPDATE	@ReturnTable
SET	    Retours = Qte
FROM    (SELECT	TEMP.Nom AS [RESULT_Nom], COUNT(DISTINCT TEMP.Numero) AS [Qte],  TEMP.FluxID AS [RESULT_FluxID], P.NumeroBadge
	    FROM	@table_temporaire AS TEMP
			INNER JOIN PASSAGES P WITH (nolock) ON P.Numero = TEMP.Numero AND P.NumeroBadge = TEMP.NumeroBadge  AND P.ResultatControle = 0	AND DateHeure > @todayDate   
      	    GROUP BY	TEMP.Nom, TEMP.FluxID, P.NumeroBadge) AS [RESULT]
WHERE Operateur = RESULT_Nom AND FluxID = RESULT_FluxID

J'aurais voulu savoir si il existe une syntaxe SQL me permettant de mettre à jour toutes les colonnes directement sachant que pour les différents UPDATE, les conditions dans les clause WHERE sont identiques. Quelque chose qui ressemblerait au code ci-dessous :

Code :

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

1
2
3
4
5
6
 
UPDATE @ReturnTable
SET  CFBon = (SELECT ... FROM ... WHERE)
SET  RetoursCF = (SELECT ... FROM ... WHERE)
...
WHERE Operateur = RESULT_Nom AND FluxID = RESULT_FluxID

D'avance merci pour vos réponses.

Dens19

[elsuket]

Bonjour,

A mon avis la première solution est la plus propre.
Dans la seconde vous allez écrire des sous requêtes avec une jointure sur la colonne de votre UPDATE, ce qui induit une jointure triangulaire, qui sera donc contre-performante.

Pourquoi avoir utilisé une table temporaire ?

@++

[dens19]

Merci de votre réponse .

Concernant votre question,

- Si vous voulez parler de la table @table_temporaire elle me sert à sauvegarder le résultat d'une requête que je réutilise à chaque fois dans mes UPDATE, je me suis dit que çà serait plus efficace que de réécrire la requête à chaque fois et par conséquent de la réexécuter également. Pensez-vous que c'est judicieux ? Existe-t'il une autre solution plus optimisée ?

- Si vous voulez parler de la table @ReturnTable j'utilise une variable table car en fait ce code se trouve dans une procédure stockée, et que plusieurs clients lourds viennent récupérer le résultat de cette procédure stockée parfois simultanément mais en ayant passé des paramètres différents.
Une table variable est donc créée à chaque fois que la procédure est appelée afin de garantir l'intégrité de mes données pour les différents clients lourds.

[elsuket]

- Si vous voulez parler de la table @table_temporaire elle me sert à sauvegarder le résultat d'une requête que je réutilise à chaque fois dans mes UPDATE, je me suis dit que çà serait plus efficace que de réécrire la requête à chaque fois et par conséquent de la réexécuter également. Pensez-vous que c'est judicieux ? Existe-t'il une autre solution plus optimisée ?

Le mieux reste d'écrire une requête purement ensembliste.
Les tables temporaires, comme toute table, sont crées dans la base de données TempDB, ce qui permet de garantir leur intégrité. SQL Server se sert massivement de cette BD pour bien d'autres tâches (pour s'en convaincre il suffit de déployer la node "Tables temporaires" de cette base).
Comme vous avez stocké vos données dans une variable table, SQL Server ne maintient pas de statistiques sur les valeurs que vous y stockez.
Donc les performances de votre requête seront pauvres.
A l'inverse, même si vous les stockiez dans une table #, vous obligez SQL Server à maintenir des statistiques sur des données que vous avez déjà, donc c'est aussi contre-performant.

- Si vous voulez parler de la table @ReturnTable j'utilise une variable table car en fait ce code se trouve dans une procédure stockée, et que plusieurs clients lourds viennent récupérer le résultat de cette procédure stockée parfois simultanément mais en ayant passé des paramètres différents.

C'est clairement impossible.
Une application ouvre une connexion, exécute une procédure stockée, récupère le résultat s'il y a lieu, et ferme la connexion.

Si votre application appelle de nombreuses fois la même procédure stockée avec des valeurs de paramètre différents, l'optimiseur de requête crée alors un plan de requête paramétré.
Sachez que pour toute requête, SQL Server a besoin de statistiques pour calculer un plan optimal, et qu'avec des variables tables vos l'en empêchez.

Si vous avez besoin de ces résultats de façon plus "pérenne", pourquoi ne pas spécifier une vue ?

@++

[SQLpro]

Ou d'utiliser une CTE pour l'UPDATE final....

A +

[dens19]

Merci de vos réponses.

Mes connaissances en SQL sont encore limitées et je crois que ce forum va grandement m'aider .

Pour ce qui est de l'utilisation de la table temporaire "@table_temporaire", je la supprimerai donc pour écrire une requête purement ensembliste.

Pour ce qui est de la table "@ReturnTable", je me suis mal exprimé, en effet il s'agit de l'exécution de la procédure stockée et non pas de l'accès simultané aux résultats cette procédure en fonction d'une connexion donnée .

Merci encore de vos réponses.

[dens19]

Merci de vos réponses.

Mes connaissances en SQL sont encore limitées et je crois que ce forum va grandement m'aider .

Pour ce qui est de l'utilisation de la table temporaire "@table_temporaire", je la supprimerai donc pour écrire une requête purement ensembliste.

Pour ce qui est de la table "@ReturnTable", je me suis mal exprimé, en effet il s'agit de l'exécution de la procédure stockée et non pas de l'accès simultané aux résultats cette procédure en fonction d'une connexion donnée .

Merci encore de vos réponses.