Hola, hemos encontrado la solución a tu búsqueda, desplázate y la verás un poco más abajo.
-
Declaración preparada: una referencia a una rutina de consulta preinterpretada en la base de datos, lista para aceptar parámetros
-
Consulta parametrizada: una consulta realizada por su código de tal manera que está pasando valores en junto a algunos SQL que tienen valores de marcador de posición, generalmente
?o%so algo de ese sabor.
La confusión aquí parece provenir de la (aparente) falta de distinción entre la capacidad de obtener directamente un objeto de declaración preparado y la capacidad de pasar valores a un método de ‘consulta parametrizada’ que actúa de manera muy similar a uno … porque es uno , o al menos te hace uno.
Por ejemplo: la interfaz C de la biblioteca SQLite3 tiene muchas herramientas para trabajar con objetos de declaración preparados, pero la API de Python casi no los menciona. No puede preparar una declaración y usarla varias veces cuando lo desee. En su lugar, puede utilizar sqlite3.executemany(sql, params) que toma el código SQL, crea una declaración preparada internamente, luego usa esa declaración en un ciclo para procesar cada una de sus tuplas de parámetros en el iterable que proporcionó.
Muchas otras bibliotecas SQL en Python se comportan de la misma manera. Trabajar con objetos de declaración preparados puede ser un verdadero dolor de cabeza y puede generar ambigüedad, y en un lenguaje como Python, que se inclina tanto hacia la claridad y la facilidad sobre la velocidad de ejecución en bruto, no es realmente la mejor opción. Esencialmente, si tiene que hacer cientos de miles o millones de llamadas a una consulta SQL compleja que se reinterpreta cada vez, probablemente debería hacer las cosas de manera diferente. Independientemente, a veces la gente desea poder tener acceso directo a estos objetos porque si mantiene la misma declaración preparada en el servidor de la base de datos no tendrá que seguir interpretando el mismo código SQL una y otra vez; la mayoría de las veces, esto abordará el problema desde la dirección incorrecta y obtendrá ahorros mucho mayores en otros lugares o reestructurando su código. *
Quizás lo más importante en general es la forma en que las declaraciones preparadas y las consultas parametrizadas mantienen sus datos sanos y separados de su código SQL. Esto es mucho mejor que string formateo! Debe pensar en consultas parametrizadas y declaraciones preparadas, de una forma u otra, como la única forma de pasar datos variables de su aplicación a la base de datos. Si intenta construir la instrucción SQL de otra manera, no solo se ejecutará significativamente más lento sino que será vulnerable a otros problemas.
* por ejemplo, produciendo los datos que se van a introducir en la base de datos en una función de generador y luego usando executemany() para insertarlo todo a la vez desde el generador, en lugar de llamar execute() cada vez que haces un bucle.
tl; dr
Una consulta parametrizada es una operación única que genera una declaración preparada internamente, luego pasa sus parámetros y se ejecuta.
editar: ¡Mucha gente ve esta respuesta! También quiero aclarar que muchos motores de base de datos también tienen conceptos de una declaración preparada que se puede construir explícitamente con sintaxis de consulta de texto sin formato y luego reutilizar durante la vida útil de la sesión de un cliente (en postgres, por ejemplo). A veces, puede controlar si el plan de consultas se almacena en caché para ahorrar aún más tiempo. Algunos marcos los usan automáticamente (he visto que el ORM de rails lo hace de manera agresiva), a veces de manera útil y, a veces, en detrimento de ellos cuando hay permutaciones de forma para las consultas que se están preparando.
Además, si desea seleccionar nit, las consultas parametrizadas no siempre use una declaración preparada debajo del capó; deberían hacerlo si es posible, pero a veces solo se trata de formatear en los valores de los parámetros. La diferencia real entre ‘declaración preparada’ y ‘consulta parametrizada’ aquí es realmente solo la forma de la API que usa.
Primero, sus preguntas muestran una muy buena preparación, bien hecha.
No estoy seguro si soy la persona que debe dar una respuesta autorizada, pero intentaré explicar mi comprensión de la situación.
Declaración preparada es un objeto, creado en el lado del servidor de base de datos como resultado de PREPARE
declaración, convirtiendo la declaración SQL proporcionada en una especie de procedimiento temporal con parámetros. La declaración preparada tiene la duración de la sesión actual de la base de datos y se descarta una vez finalizada la sesión. Declaración SQL DEALOCATE permite destruir la declaración preparada explícitamente.
Los clientes de la base de datos pueden usar la declaración SQL EXECUTE para ejecutar la declaración preparada llamando a su nombre y parámetros.
Declaración parametrizada es un alias para la declaración preparada como de costumbre, la declaración preparada tiene algunos parámetros.
Consulta parametrizada parece ser un alias menos utilizado para el mismo (24 mil hits de Google para la declaración parametrizada, 14 mil hits para la consulta parametrizada). Es posible que algunas personas usen este término para otro propósito.
Las ventajas de las declaraciones preparadas son:
- ejecución más rápida de la llamada de declaración preparada real (sin contar el tiempo para
PREPARE) - resistencia al ataque de inyección SQL
Jugadores en la ejecución de consultas SQL
La aplicación real probablemente tendrá los siguientes participantes:
- código de aplicación
- Paquete ORM (por ejemplo, sqlalchemy)
- controlador de base de datos
- servidor de base de datos
Desde el punto de vista de la aplicación, no es fácil saber si el código realmente utilizará la declaración preparada en el servidor de la base de datos o no como cualquiera de los participantes puede carecer del apoyo de las declaraciones preparadas.
Conclusiones
En el código de la aplicación evitar la configuración directa de consultas SQL, ya que es propenso a ataques de inyección SQL. Por esta razón, se recomienda usar todo lo que el ORM proporcione a la consulta parametrizada, incluso si no resulta en el uso de declaraciones preparadas en el lado del servidor de la base de datos, ya que el código ORM se puede optimizar para evitar este tipo de ataque.
Decidir si la declaración preparada vale por razones de desempeño.. Si tiene una consulta SQL simple, que se ejecuta solo unas pocas veces, no ayudará, en ocasiones incluso ralentizará un poco la ejecución.
Para consultas complejas que se ejecutan muchas veces y que tienen un tiempo de ejecución relativamente corto, el efecto será el mayor. En tal caso, puede seguir estos pasos:
- compruebe que la base de datos que va a utilizar admita la
PREPAREdeclaración. En la mayoría de los casos estará presente. - compruebe que la unidad que utiliza admita declaraciones preparadas y, si no es así, intente encontrar otra que la admita.
- Verifique el soporte de esta función en el nivel de paquete ORM. En ocasiones, varía de un controlador a otro (por ejemplo, sqlalchemy establece algunas limitaciones en las declaraciones preparadas con MySQL debido a cómo MySQL administra eso).
Si está buscando una respuesta real autorizada, me dirigiría a los autores de sqlalchemy.
Calificaciones y comentarios
Si haces scroll puedes encontrar las reseñas de otros creadores, tú también eres capaz dejar el tuyo si lo deseas.