Su código de ejemplo es tan simple que habrá poca diferencia, pero en ese caso, la versión estática probablemente se ejecutaría mejor.
La razón principal para usar SQL dinámico para el rendimiento es cuando la declaración SQL puede variar de manera significativa, es decir, es posible que pueda agregar código adicional a la cláusula WHERE en tiempo de ejecución según el estado del sistema (restringido por una subconsulta en la dirección, si se ingresó la dirección, etc.).
Otra razón es que, a veces, usar variables Bind como parámetros puede ser contraproducente.
Un ejemplo es si tiene algo como un campo de estado, donde los datos no se distribuyen uniformemente (pero están indexados).
Considere las siguientes 3 declaraciones, cuando el 95% de los datos se 'Procesan
SELECT col FROM table
WHERE status = 'U'-- unprocessed
AND company = :company
SELECT col FROM table
WHERE status = 'P' -- processed
AND company = :company
SELECT col FROM table
WHERE status = :status
AND company = :company
En la versión final, Oracle elegirá un plan de explicación genérico. En la primera versión, puede decidir que el mejor plan es comenzar con el índice de estado (sabiendo que las entradas "no procesadas" son una parte muy pequeña del total).
Podría implementar eso a través de diferentes declaraciones estáticas, pero donde tiene declaraciones más complejas que solo cambian por un par de caracteres, SQL dinámico puede ser una mejor opción.
Desventajas
Cada repetición de la misma declaración SQL dinámica incurre en un análisis suave, que es una pequeña sobrecarga en comparación con una declaración estática, pero sigue siendo una sobrecarga.
Cada instrucción SQL NUEVA (dinámica o estática) también incurre en un bloqueo en la SGA (memoria compartida) y puede resultar en la eliminación de declaraciones 'antiguas'.
Un diseño de sistema malo, pero común, es que alguien use SQL dinámico para generar selecciones simples que solo varían según la clave, es decir,
SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7
Las declaraciones individuales serán rápidas, pero el rendimiento general del sistema se deteriorará, ya que está acabando con los recursos compartidos.
Además, es mucho más difícil atrapar errores en tiempo de compilación con SQL dinámico. Si usa PL/SQL, esto es descartar una buena verificación del tiempo de compilación. Incluso cuando usa algo como JDBC (donde mueve todo el código de su base de datos a cadenas, ¡buena idea!), Puede obtener analizadores previos para validar el contenido de JDBC. SQL dinámico =solo prueba en tiempo de ejecución.
Gastos generales
La sobrecarga de ejecución inmediata es pequeña, está en las milésimas de segundo, sin embargo, puede sumarse si está dentro de un bucle / en un método llamado una vez por objeto / etc. Una vez obtuve una mejora de velocidad de 10x al reemplazar dinámico SQL con SQL estático generado. Sin embargo, esto complicó el código y solo se hizo porque necesitábamos la velocidad.
