He estado leyendo mucho sobre declaraciones preparadas y en todo lo que he leído, nadie habla sobre los inconvenientes de usarlas. Por lo tanto, me pregunto si hay algún lugar donde haya "dragones" que las personas tienden a pasar por alto.¿Hay inconvenientes en el uso de declaraciones preparadas?
La declaración preparada es solo una declaración procesada y precompilada SQL que simplemente espera a que se entreguen las variables enlazadas para su ejecución.
Cualquier instrucción ejecutada se prepara tarde o temprano (necesita ser analizada, optimizada, compilada y luego ejecutada).
Una declaración preparada simplemente reutiliza los resultados del análisis sintáctico, la optimización y la compilación.
Por lo general, los sistemas de bases de datos utilizan algún tipo de optimización para ahorrar tiempo en la preparación de consultas, incluso si usted no usa las consultas preparadas usted mismo.
Oracle, por ejemplo, al analizar primero una consulta comprueba la memoria caché de la biblioteca, y si la misma declaración ya se ha analizado, utiliza el plan de ejecución en caché en su lugar.
Creo que a esta respuesta le falta un problema clave con las declaraciones preparadas, ej. que el plan de consulta se optimiza de acuerdo con las estadísticas de datos presentes en el momento en que se prepara la consulta, y puede no ser óptimo en el futuro, cuando se ejecuta la consulta. Entonces este es un inconveniente de una declaración preparada. – egbokul
Algunos artículos que mencionan un inconveniente similar: https://medium.com/@devinburnette/be-prepared-7768d1a111e1 --- y --- https: //www.vividcortex.com/blog/2014/11/19/analyzing-prepared-statement-performance-with-vividcortex/ – MarsAndBack
Si usa una instrucción solo una vez, o si genera automáticamente sentencias SQL dinámicas (y escapa totalmente o sabe con certeza que sus parámetros tienen solo caracteres seguros), entonces no debe usar declaraciones preparadas.
Por supuesto, esto es extremadamente raro. Me resulta mucho más fácil simplemente tener las cosas de la declaración preparada en el lado del servidor para la desinfección de la entrada. – Powerlord
El único inconveniente que se me ocurre es que ocupan memoria en el servidor. No es mucho, pero probablemente haya algunos casos extremos en los que sería un problema, pero me cuesta pensar en alguno.
Hay otro pequeño problema con declaraciones preparadas frente a sql dinámico, y es que puede ser más difícil depurarlas. Con sql dinámico, siempre puede escribir una consulta de problema en un archivo de registro y ejecutarla directamente en el servidor exactamente como lo ve su programa. Con las declaraciones preparadas puede tomar un poco más de trabajo probar su consulta con un conjunto específico de parámetros determinados a partir de los datos del bloqueo. Pero no mucho más, y la seguridad adicional definitivamente justifica el costo.
En algunas situaciones, el motor de la base de datos puede llegar a un plan de consulta inferior cuando usa una declaración preparada (porque no puede hacer las suposiciones correctas sin tener los valores de vinculación reales para una búsqueda).
véase, p. la sección "Notas" en
http://www.postgresql.org/docs/current/static/sql-prepare.html
por lo que podría valer la pena probar sus consultas con y sin la preparación de estados para averiguar cuál es más rápido. idealmente, usted decidiría según el enunciado si usar declaraciones preparadas o no, aunque no todos los ORM le permitirán hacer eso.
He descubierto que el mejor patrón es utilizar un enfoque de todo o nada para las declaraciones preparadas. El DBMS es más inteligente que la mayoría de nosotros, y puede descubrir el mejor plan la mayor parte del tiempo. También estoy seguro de que sabe que los diferentes SGBD tendrán diferentes estrategias de plan de consulta, por lo que el enlace no se debe usar como un resumen para las declaraciones preparadas. Si está utilizando su DBMS para el trabajo web, la manera más rápida y fácil de defenderse contra los ataques de inyección SQL es usar siempre declaraciones preparadas. – bakoyaro
Todo en TI tiene inconvenientes, solo necesita comprobar si realmente vale la pena preocuparse por su problema específico. :) Este enlace en SO http://stackoverflow.com/questions/535464/when-not-to-use-prepared-statements/537834 tiene algunos ejemplos sobre desventajas de declaraciones preparadas. – GmonC