272
Chapitre 8. Optimisation du code SQL
ment à la création de la table), comme il est impossible d’y appliquer après création
toute commande DDL. Ainsi, les variables ne doivent pas être utilisées pour remplacer des tables temporaires volumineuses sur lesquelles on effectue beaucoup d’opérations de recherche.
Nous l’avons dit, les opérations sur la variable ne sont pas enrôlées dans une transaction. La différence est simple à expérimenter :
USE tempdb
GO
CREATE TABLE #t (Name SYSNAME)
BEGIN TRAN
INSERT #t SELECT name FROM [master].[dbo].[sysobjects]
ROLLBACK
SELECT * FROM #t
GO
DECLARE @t TABLE (Name SYSNAME)
BEGIN TRAN
INSERT @t SELECT name FROM [master].[dbo].[sysobjects]
ROLLBACK
SELECT * FROM @t
GO
Dans la première partie du code, nous utilisons une table temporaire, dans
laquelle nous insérons des lignes à l’intérieur d’une transaction explicite. Après
l’annulation de la transaction (ROLLBACK), la table est vide : l’insertion a été annulée.
En revanche, l’application du même code à la variable de type table montre que,
même après le ROLLBACK, les lignes insérées sont toujours dans la variable. Bien que
bénéfique pour les performances, ce comportement est évidemment dangereux : si
vous codez des transactions impliquant des variables de type table, vous risquez
d’obtenir des résultats inattendus.
En conclusion, Microsoft recommande de remplacer les tables temporaires par
des variables autant que possible. Précisons donc qu’elles ne sont intéressantes que
lorsqu’elles sont de petite taille, pour des opérations simples, et bien entendu,
lorsqu’on ne peut les remplacer par des jointures, des sous-requêtes ou des expressions de table.
8.3.2 Pour ou contre le SQL dynamique
Le sujet fait débat. Que penser du SQL dynamique ? C’est ainsi qu’est appelée la
possibilité de générer une instruction SQL, plus ou moins complexe, dans une
Chapitre 8. Optimisation du code SQL
ment à la création de la table), comme il est impossible d’y appliquer après création
toute commande DDL. Ainsi, les variables ne doivent pas être utilisées pour remplacer des tables temporaires volumineuses sur lesquelles on effectue beaucoup d’opérations de recherche.
Nous l’avons dit, les opérations sur la variable ne sont pas enrôlées dans une transaction. La différence est simple à expérimenter :
USE tempdb
GO
CREATE TABLE #t (Name SYSNAME)
BEGIN TRAN
INSERT #t SELECT name FROM [master].[dbo].[sysobjects]
ROLLBACK
SELECT * FROM #t
GO
DECLARE @t TABLE (Name SYSNAME)
BEGIN TRAN
INSERT @t SELECT name FROM [master].[dbo].[sysobjects]
ROLLBACK
SELECT * FROM @t
GO
Dans la première partie du code, nous utilisons une table temporaire, dans
laquelle nous insérons des lignes à l’intérieur d’une transaction explicite. Après
l’annulation de la transaction (ROLLBACK), la table est vide : l’insertion a été annulée.
En revanche, l’application du même code à la variable de type table montre que,
même après le ROLLBACK, les lignes insérées sont toujours dans la variable. Bien que
bénéfique pour les performances, ce comportement est évidemment dangereux : si
vous codez des transactions impliquant des variables de type table, vous risquez
d’obtenir des résultats inattendus.
En conclusion, Microsoft recommande de remplacer les tables temporaires par
des variables autant que possible. Précisons donc qu’elles ne sont intéressantes que
lorsqu’elles sont de petite taille, pour des opérations simples, et bien entendu,
lorsqu’on ne peut les remplacer par des jointures, des sous-requêtes ou des expressions de table.
8.3.2 Pour ou contre le SQL dynamique
Le sujet fait débat. Que penser du SQL dynamique ? C’est ainsi qu’est appelée la
possibilité de générer une instruction SQL, plus ou moins complexe, dans une