![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Comparativa entre los servicios de consulta dinámica y de EJB de despliegue
Puede utilizar el servicio de consulta dinámica para crear y ejecutar consultas con beans de entidad construidos dinámicamente en el momento de la ejecución, en lugar de definirlos en el momento del despliegue. Mediante el uso de la consulta dinámica, se consigue la flexibilidad de las consultas definidas en el tiempo de ejecución y se utiliza la potencia del lenguaje de consulta (QL) de EJB (Enterprise JavaBeans). Aparte de dar soporte a todas las funciones de una consulta EJB-QL, la consulta dinámica añade funciones que no están disponibles para la consulta estática estándar. Dos ejemplos son la posibilidad de seleccionar varios campos de datos directamente desde el propio bean (las consultas estáticas actualmente sólo permiten uno) y ejecutar los métodos de negocio directamente en la consulta.
Con las consultas dinámicas, se pueden crear aplicaciones más eficaces y con un consumo menor de recursos. Por ejemplo, se necesitan dos campos de datos de los resultados de una consulta. Como una consulta EJB-QL sólo puede seleccionar un campo de datos, es necesario seleccionar todo el objeto EJB y extraer los datos necesarios a partir de los resultados devueltos en los métodos de acceso a datos, probablemente a través de los límites de CMR (Container Managed Relationships) en el proceso. Sin embargo, cuando se utiliza la consulta dinámica, se pueden obtener ambos datos directamente de la consulta, sin necesidad de pasar a través de las CMR ni de métodos accesores. Este principio es la clave para evaluar si se pueden utilizar la consulta dinámica para aumentar el rendimiento. Revise la cantidad de datos que se deben recuperar, además de la cantidad de lógica empresarial que se necesita para recuperarlos, por ejemplo, métodos accesores o el paso a través de CMR.
Otra de las consideraciones sobre el rendimiento es el uso de parámetros en la consulta en lugar de valores literales. En la mayoría de casos, es mejor definir valores condicionales como parámetros en la consulta y pasar luego esos parámetros a través de los mecanismos adecuados. Con este método, la probabilidad de encontrar un plan de consulta que coincida en la memoria caché es mayor, y ya no es necesario analizar y crear el plan desde cero. Por ejemplo, "SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE foo" se expresa mejor como "SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE ?1" donde el valor foo se pasa como parámetro al método executeQuery. El resultado es que las siguientes ejecuciones de una estructura de consulta dinámica que sea la misma, excepto en el caso de condiciones de literales de serie diferentes, se registran como aciertos en la memoria caché de planes, que genera un rendimiento "observado" mejor.
Cuando se utiliza sustituyendo directamente a una consulta estática equivalente, la consulta dinámica es aproximadamente un 25 % más lenta que la variación estática. Esta ralentización se debe a la necesidad de analizar y crear un plan para la consulta, además de ejecutarla. En la variación estática, estos costes se pagan en el momento del despliegue. A pesar de esto, las funciones adicionales que se consiguen gracias al uso de las consultas dinámicas, en concreto la posibilidad de seleccionar varios campos de datos en una sola consulta a través de CMR, ofrecen nuevas formas de utilizar la consulta dinámica para mejorar el rendimiento.