En los post anteriores hemos visto como las consultas parametrizadas nos ayudan a evitar el SQL Inyection .Sin embargo hacen bastante mas que evitarnos ese problema ya que permiten mejorar el rendimiento de las consultas que ejecutamos . Para entender esto vamos a ver una serie de diagramas que exponen a grosso modo como una consulta SQL que nosotros construimos es tratada por el motor de base de datos.
- El primer paso es realizar un analisis sintáctico de la consulta para comprobar que no hay palabras reservadas incorrectas o que se han usado palabras reservadas no válidas.
- Una vez realizado este primer paso . El segundo paso trata de realizar un análisis semantico del texto comprobando que las tablas y columnas solicitadas existen y tenemos permisos
- En tercer lugar y aqui viene una parte importante se realiza un HASH de la consulta que la identifica de forma única y es guardado en memoria.
Una vez realizados estos tres primeros pasos la consulta pasa por los siguientes pasos adicionales.
- En cuarto lugar se reservar memoria para la ejecución de la consulta
- En quinto lugar se optimiza la consulta y se genera un plan de ejecución que define a que tablas e indices debe la base de datos acceder para realizar la consulta.
- Se abre un cursor se ligan las valores de la consulta (‘juan’) a variables de la propia consulta y se ejecuta
- Se recogen los datos que la consulta devuelve .
- Al haberse ejecutado la consulta sin ningún problema se cachea el plan de ejecución junto con el código HASH que identificada la consulta
De esta manera si en algún momento volvemos a lanzar la misma consulta . Se volvera a generar el mismo HASH y el plan de ejecución se encontrará cacheado. Ahora bien si nosotros ejecutamos las siguientes dos consultas.
Nos podemos dar cuenta que aunque la consulta es idéntica y unicamente cambia el valor del nombre . Los hash que se generan son distintos. Esto producirá que si ejecutamos dos consultas con nombres distintos se generen dos planes de ejecución y el servidor de base de datos realice todos los pasos (1-8) .Ahora bien si nosotros no lanzamos una consulta normal sino una consulta parametrizada en la cual los parámetros son variables ? se generará el mismo HASH .
De esta manera la base de datos podrá reutilizar el mismo plan de ejecución y reducir los pasos a realizar al lanzar la consulta SQL mejorando el rendimiento.
Aunque parece que nos hemos ahorrado solo un par de pasos el paso de Optimización y construcción del plan de ejecución es uno de los que mas recursos consume. Así pues el uso de consultas parametrizadas no solo nos ayudará a evitar los SQL Inyection sino que ademas nos puede ayudar a mejorar el rendimiento a nivel de motor de base de datos . Los pasos aqui descritos son en lineas generales ya que cada motor de base de datos es particular y puede haber diferencias.
Gracias por el aporte; la verdad es que me ha venido muy bien para una explicación de clase. 😉
Un cordial saludo
de nada 🙂
Hola Cecilio, primero agradecerte por los aportes que nos brindas a toda la comunidad. Estoy aprendiendo java guiándome de tu libro Aquitectura Java Sólida, voy en la página 96, tema de excepciones, en el punto 7. Modificar fichero web.xml he implementado como indicas pero cuando hago una inserción con clave duplicada ocurre el error pero no carga la pagina Error.jsp me aparece el mensaje “El sitio web no puede mostrar la página”. Por favor te agradeceré me puedas indicar que tengo que corregir.
Muchas gracias.
Saludos
Ysrael
Has configurado en el web.xml las páginas de error para que detecte las diferentes excepciones?
Hola Cecilio, gracias por responder, todo esta bien, ya funciona correctamente, solo tenia que ejecutarlo desde el explorador de internet y no en el eclipse.
Saludos
Ysrael
Muy interesante! Gracias.
de nada 🙂
Excelente muy buena explicacio 🙂
gracias
Muy buena explicacion… espero muchos programadores vean este post
me alegro te fuera util 🙂
Si, muy buena. Las explicaciones que tengo escuchado sobre el tema siempre se referían y se quedaban con el tema de evitar SQL inyection, creo que una vez escuché alguna explicación que refería el tema de rendimiento pero sin dar explicación.
Muy aclaratorio.
Muy buena explicación, muy clarificadora. Enhorabuena y gracias.