Le traducteur SQL améliore les performances des requêtes en générant un code optimisé qui permet au moteur de récupération sous-jacent d'accéder directement aux enregistrements sélectionnés, sans balayer toutes les instances de segments.
Pour plus d'informations sur l'optimisation d'index et les déclarations jointes optimisées, consultez la documentation iWay relative à votre plate-forme.
x
Le traducteur SQL prend en charge des jointures dans la syntaxe SQL. Les jointures du langage SQL n'ont pas de direction implicite. Le concept de fichiers hôte et de référence croisée n'existe pas dans SQL.
Le traducteur SQL analyse chaque jointure afin d'identifier l'implémentation le plus efficace. Pour commencer, il attribue un coût (Cost) aux jointures candidates dans la requête :
- Cost = 1 pour une équijonction vers un champ qui peut servir de champ de référence selon les règles de jointures de FOCUS. Cela est courant dans les interrogations des tableaux relationnels avec des prédicats d'équijonction dans la clause WHERE.
- Cost = 16 pour une équijonction vers un champ qui ne peut pas servir de champ de référence selon les règles de jointure de FOCUS.
- Cost = 256 pour une non équijonction ou un produit cartésien sans limitation.
Ensuite, le traducteur utilise ces coûts pour créer une structure de jointure pour l'interrogation. L'ordre des tableaux dans la clause FROM de l'interrogation influence les deux premières phases de l'analyse de jointure :
- S'il y a des jointures cost=1 du premier tableau référencées dans la clause FROM vers le deuxième tableau, et du deuxième vers le troisième, et ainsi de suite, le traducteur joint les tableaux dans l'ordre spécifié dans l'interrogation. Sinon, il passe à la phase 2.
- Si la phase 1 ne réussit pas à générer une structure de jointure acceptable, le traducteur essaie de générer une structure de jointure sans joindre un tableau à un tableau qui le précède dans la clause FROM. Par conséquent, cette phase rend toujours le premier tableau référencé dans l'interrogation le tableau hôte. S'il n'y a pas de jointure cost=1 entre deux tableaux, ou si l'utilisation d'une jointure cost=1 implique de changer l'ordre des tableaux, le traducteur renonce à la phase 2 et met en œuvre la phase 3.
- Le traducteur génère la structure de jointure à partir des jointures aux coûts les plus bas en premier, puis des jointures plus chères, le cas échéant. Ce processus de traitement peut changer l'ordre dans lequel les tableaux sont joints. L'efficacité de la jointure générée par cette procédure dépend des tailles relatives des tableaux que l'on joint.
Si l'analyse a pour résultat la jointure d'un tableau qui ne peut pas servir de fichier de référence selon les règles de FOCUS (car il manque d'index, par exemple), le traducteur génère le code pour créer un fichier HOLD indexé, et implémente la jointure dans ce fichier. Cependant, le fichier HOLD ne participe pas à l'analyse de l'ordre de jointure.