Creación de procedimiento almacenado y SQLite?

181

¿De alguna manera es posible crear un procedimiento almacenado cuando se usa SQLite?

sqlite stored-procedures

— grady
fuente

217

SQLite ha tenido que sacrificar otras características que algunas personas encuentran útiles, como alta concurrencia, control de acceso específico, un amplio conjunto de funciones integradas, procedimientos almacenados , características de lenguaje SQL esotérico, extensiones XML y / o Java, tera- o escalabilidad peta-byte, y así sucesivamente

Fuente: Usos apropiados para SQLite

— h3xStream
fuente

3

Puede usar el equivalente SQLite de las funciones SQL CLR para lograr el mismo objetivo ( stackoverflow.com/questions/172735/… ).

— devinbost

@bostIT Gracias por la adición. Ref. Para System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki

— h3xStream

91

Respuesta : NO

He aquí por qué ... Creo que una razón clave para tener los procesos almacenados en una base de datos es que está ejecutando el código SP en el mismo proceso que el motor SQL. Esto tiene sentido para los motores de bases de datos diseñados para funcionar como un servicio conectado a la red, pero el imperativo de SQLite es mucho menor dado que se ejecuta como un archivo DLL en el proceso de su aplicación en lugar de en un proceso separado del motor SQL. Por lo tanto, tiene más sentido implementar toda su lógica de negocios, incluido lo que habría sido el código SP en el idioma del host.

Sin embargo, puede extender SQLite con sus propias funciones definidas por el usuario en el lenguaje host (PHP, Python, Perl, C #, Javascript , Ruby , etc.). Luego puede usar estas funciones personalizadas como parte de cualquier selección / actualización / inserción / eliminación de SQLite. He hecho esto en C # usando SQLite de DevArt para implementar el hash de contraseña.

— Tony O'Hagan
fuente

16

Para aclarar ... No estoy diciendo que NO haya razón para implementar SP en SQLite, solo mucho menos razón que en otros motores de base de datos.

— Tony O'Hagan

44

La razón CLAVE para tener procedimientos almacenados es evitar la inyección SQL. Sin embargo, hay muchas otras razones. Por ejemplo, poder compartir las consultas relevantes incrustándolas en el archivo sqlite. No hay absolutamente ninguna diferencia entre una consulta estándar que se ejecuta en el contexto del motor SQL y la selección de un SP. Ambos están CORRIENDO en el MOTOR SQL.

— Dan

44

@Dan Primero, los SP existían mucho antes de que se pensara en la inyección SQL. Se han creado miles de aplicaciones basadas en SQL sin ellas que son seguras contra este ataque. También he revisado el código de SP inseguros que son vulnerables a la inyección de SQL (generalmente basados en SQL dinámico). Entonces no, no, esta es una razón principal. Hay muchas otras formas de prevenir este ataque más arriba en la pila.

— Tony O'Hagan el

3

@Dan La mayoría de los motores SQL son cliente / servidor (¡NO SQLite!). Para estos, el rendimiento es un tema clave al decidir dónde colocar la lógica de su negocio. La ejecución de la lógica de negocios ya sea consulta O código interactivo O condicional dentro de un SP en el motor SQL puede (1) mejorar el rendimiento de recuperación de datos, (2) reducir el tráfico de red (3) reducir el uso de memoria de la capa de aplicación (4) planes de ejecución de consultas de caché (precompilado SP). La mayoría de los desarrolladores de aplicaciones prefieren mover algo de su lógica de negocios fuera del motor SQL (¡obviamente no las consultas!). Para SQLite, esto es menos imperativo ya que no es compatible con el cliente / servidor.

— Tony O'Hagan el

Gracias Tony. Me preguntaba por qué SQLite no tiene procedimientos pero tiene funciones integradas ( sqlite.org/lang_corefunc.html )? ¿Es correcto que para RDBMS cliente-servidor como postgresql, ambas funciones y procedimientos se almacenen en el lado del servidor? Dado que SQLite no tiene servidor, si SQLite no tiene procedimientos, entonces, por la misma razón, ¿tampoco debería tener funciones?

— Tim

17

Si todavía está interesado, Chris Wolf realizó una implementación prototipo de SQLite con procedimientos almacenados. Puede encontrar los detalles en su publicación de blog: Agregar procedimientos almacenados a SQLite

— torial
fuente

55

El artículo está muerto ahora, pero el proyecto está en github.com/wolfch/sqlite-3.7.3.p1 . El archivo readme implica que esto no está listo para producción, ni para experimentación. Parece que es más una prueba de concepto.

— pqsk

7

Sin embargo, es posible falsificarlo usando una tabla dedicada, llamada así por tu falso-sp, con un disparador DESPUÉS DE INSERTAR. Las filas de la tabla dedicada contienen los parámetros para su sp falsa, y si necesita devolver resultados, puede tener una segunda tabla (pos. Temp) (con nombre relacionado con la fake-sp) para contener esos resultados. Requeriría dos consultas: primero para INSERTAR datos en la tabla de desencadenadores de fake-sp, y el segundo para SELECCIONAR desde la tabla de resultados de fake-sp, que podría estar vacía, o tener un campo de mensaje si algo salía mal .

— slashmais
fuente