Performances SQL dynamiques dans ODBC
Bien que sql statique fonctionne bien dans de nombreuses situations, il existe une classe d’applications dans laquelle l’accès aux données ne peut pas être déterminé à l’avance. Par exemple, supposons qu’une feuille de calcul permet à un utilisateur d’entrer une requête, que la feuille de calcul envoie ensuite au SGBD pour récupérer des données. Le contenu de cette requête ne peut évidemment pas être connu du programmeur lorsque le programme de feuille de calcul est écrit.
Exécution dynamique
Pour résoudre ce problème, la feuille de calcul utilise une forme de SQL incorporée appelée SQL dynamique. Contrairement aux instructions SQL statiques, qui sont codées en dur dans le programme, les instructions SQL dynamiques peuvent être générées au moment de l’exécution et placées dans une variable hôte de chaîne. Ils sont ensuite envoyés au SGBD pour traitement. Étant donné que le SGBD doit générer un plan d’accès au moment de l’exécution pour les instructions SQL dynamiques, sql dynamique est généralement plus lent que SQL statique. Lorsqu’un programme contenant des instructions SQL dynamiques est compilé, les instructions SQL dynamiques ne sont pas supprimées du programme, comme dans SQL statique. Au lieu de cela, ils sont remplacés par un appel de fonction qui transmet l’instruction au SGBD ; Les instructions SQL statiques dans le même programme sont traitées normalement.
La façon la plus simple d’exécuter une instruction SQL dynamique est d’utiliser une instruction EXECUTE IMMEDIATE. Cette instruction transmet l’instruction SQL au SGBD pour la compilation et l’exécution.
L’un des inconvénients de l’instruction EXECUTE IMMEDIATE est que le SGBD doit parcourir chacune des cinq étapes de traitement d’une instruction SQL chaque fois que l’instruction est exécutée. La surcharge impliquée dans ce processus peut être importante si de nombreuses instructions sont exécutées dynamiquement, et il est gaspiller si ces instructions sont similaires.
Exécution préparée
Pour résoudre la situation ci-dessus, sql dynamique offre une forme optimisée d’exécution appelée exécution préparée, qui utilise les étapes suivantes :
Le programme construit une instruction SQL dans une mémoire tampon, tout comme pour l’instruction EXECUTE IMMEDIATE. Au lieu de variables hôtes, un point d’interrogation ( ?) peut être remplacé par une constante n’importe où dans le texte de l’instruction pour indiquer qu’une valeur pour la constante sera fournie ultérieurement. Le point d’interrogation est appelé comme marqueur de paramètre.
Le programme transmet l’instruction SQL au SGBD avec une instruction PREPARE, qui demande que le SGBD analyse, valide et optimise l’instruction et génère un plan d’exécution pour celui-ci. Le programme utilise ensuite une instruction EXECUTE (et non une instruction EXECUTE IMMEDIATE) pour exécuter l’instruction PREPARE ultérieurement. Il transmet des valeurs de paramètre pour l’instruction par le biais d’une structure de données spéciale appelée SQL Data Area ou SQLDA.
Le programme peut utiliser l’instruction EXECUTE à plusieurs reprises, en fournissant des valeurs de paramètre différentes chaque fois que l’instruction dynamique est exécutée.
L’exécution préparée n’est toujours pas la même que sql statique. Dans sql statique, les quatre premières étapes de traitement d’une instruction SQL ont lieu au moment de la compilation. Dans l’exécution préparée, ces étapes sont toujours effectuées au moment de l’exécution, mais elles ne sont effectuées qu’une seule fois. L’exécution du plan n’a lieu que lorsque EXECUTE est appelé. Ce comportement permet d’éliminer certains des inconvénients de performances inhérents à l’architecture de SQL dynamique.