Discussion :

[VITALTH]

Bonjour,
Voilà tous les soirs j'ai une très grosse table que je vide et mets à jour avec les données de production.
Ca prend un certains temps et j'essaie de mettre en place plusieurs optimisation en //

Cependant le principe est le suivant
1 - INSERT INTO TblToUpdate (...) SELECT (...) FROM TblSelect
2 - Plusieurs UPDATE TblToUpdate SET Chps = ...

La raison des plusiers requêtes UPDATE est que les champs sont calculés par CASE WHEN successive. Si je fais tout ça dans la même requête UPDATE je me retrouve avec une truc du genre SET Chps = CASE WHEN CASE WHEN CASE WHEN...Bref illisible et difficile à écrire sans faute.

J'ai trouvé un truc sur Google que j'ai testé qui marche pas mal
On peut faire un truc du genre

Code :

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

UPDATE TblToUpdate SET @Chps1 = Chps1 = CASE WHEN ... END, Chps2 = @Chps1 + CASE WHEN ... END

Je l'ai testé et ça ça marche bien.

Du coup pour encore gagner du temps, je m'étais proposé de tout faire dans la requête INSERT INTO et j'ai essayé un truc du genre

Code :

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

1
2
INSERT INTO TblToUpdate (Chp1, Chp2)
SELECT @Chps1 = CASE WHEN ... END, @Chps2 = @Chps1 + CASE WHEN ... END FROM TblSelect

Et là j'ai le message :

Une instruction INSERT ne peut contenir d'instruction SELECT affectant des valeurs à une variable.

J'en déduis que ce n'est pas possible dans une requête INSERT INTO.

Du coup j'ai pensé à la clause WITH et les jeux nommées dans la requête

Mais je ne suis pas sur de gagner en temps.

[aieeeuuuuu]

Bonjour,

Oui, une série de CTE successives pourrait permettre de factoriser le code, en rendant la requete plus lisible, sans affecter les performances.

Ce serait même plus propre que l'utilisation de variables.

vous pourriez aussi imbriquer des fonctions, mais en fonction du contenu de vos CASE, ça pourrait impacter les performances.

donc, la CTE me semble une bonne idée.

N'hésitez pas a venir poster le résultat !

[VITALTH]

Oui j'ai testé avec les CTE et c'est très bien.
J'avais un peu peur de plier le serveur car selon moi les requêtes WITH chargés le résultat en mémoire et comme j'avais des 10zaines de millions d'enrgt je m'attendais au pire. Mais non !!
Les CTE sont un peu magique selon moi, je ne sais pas comment ça fonctionne mais les résultats sont là.

[rudib]

Tous les résultats sont toujours chargés en mémoire. Le moteur d'exécution de SQL Server ne travaille jamais directement sur des données sur le disque, il accède aux données dan le cache de données du serveur qui s'appelle le buffer.
Le moteur d'optimisation essaie de faire du bon boulot avec ce que tu lui donnes comme requête. Le pire qui puisse t'arriver est de faire une requête trop lente. Essaie et vérifie les performances, et si ça ne passe pas, change la requête ...

[Lyche]

Regarde du côté de la clause OUTPUT.

Code sql :

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

1
2
3
4
5
6
 
INSERT INTO maTable2
SELECT *
OUTPUT INSERTED.*
   INTO uneNouvelleTable
  FROM MaTable;

Avec une nouvelle table ayant la structure des données que tu veux récupérer de ton INSERT.

Derrière, tu peux retravailler les données de façon normal et tu évites la grosse quantité de paramètre qui peuvent rendre le code parfois un peu illisibles.