SQL Translator aumenta el rendimiento de las consultas generando un código optimizado, que permite que el motor de búsqueda subyacente acceda directamente a los registros, sin examinar todos los segmentos.
Para más información acerca de la optimización de índices y declaraciones de join, consulte la documentación de su plataforma.
x
El SQL Translator acepta las joins en sintaxis SQL. Las joins en lenguaje SQL no tienen una dirección implícita. Los conceptos de archivo host y referencia cruzada no existen en SQL.
SQL Translator analiza cada join para identificar la implementación eficiente. Primero, asigna costes a las joins candidatas de la consulta:
- Cost = 1 para una equijoin con un campo que pueda participar como campo de referencia cruzada según las reglas de join de FOCUS. Esto es común en consultas contra tablas relacionales con predicados equijoin en la cláusula WHERE.
- Cost = 16 para una equijoin con un campo que no pueda participar como campo de referencia cruzada según las reglas de join de FOCUS.
- Cost = 256 para una equijoin o un producto cartesiano no restringido.
Translator usa entonces estos costes para construir una estructura join para la consulta. El orden de las tablas en la cláusula FROM de la consulta influencia las primeras dos frases del análisis de join:
- Si existen joins del tipo cost=1 desde la primera tabla mencionada en la cláusula FROM a la segunda, desde la segunda a la tercera y así sucesivamente, Translator las combina en el orden especificado en la consulta. De lo contrario, no pasa a la fase 2.
- Si la fase 1 no logra generar una estructura de join aceptable, Translator intenta generar una estructura join sin combinar ninguna tabla a una tabla precedente en la cláusula FROM. Por lo tanto, esta fase siempre convierte la primera fase mencionada en la consulta la tabla anfitriona. Si no hay join cost=1 entre dos tablas o si el uso de una requiere que se cambie el orden de la tabla, el Translator abandona la fase 2 e implementa la fase 3.
- Translator genera la estructura de join, primero desde las joins de más bajo coste y luego desde las más caras, según sea necesario. Este proceso de clasificación podría cambiar el orden en que se combinan las tablas. La eficiencia de la join generada por este procedimiento depende de los tamaños relativos de las tablas que se combinen.
Si el análisis resulta en el establecimiento de una join con una tabla que, según las reglas de FOCUS, no puede participar como archivo de referencia cruzada (porque le falta un índice, por ejemplo), el Translator genera código para construir un archivo HOLD indexado e implementa la join con este archivo. Sin embargo, el archivo HOLD no participa del análisis del orden de join.