Creazione di stored procedure e SQLite?


181

È in qualche modo possibile creare una procedura memorizzata quando si utilizza SQLite?

Risposte:


217

SQLite ha dovuto sacrificare altre caratteristiche che alcune persone trovano utili, come elevata concorrenza, controllo degli accessi a grana fine, un ricco set di funzioni integrate, procedure memorizzate , funzionalità del linguaggio SQL esoterico, estensioni XML e / o Java, tera- o scalabilità peta-byte e così via

Fonte: usi appropriati per SQLite


3
È possibile utilizzare l'equivalente SQLite delle funzioni CLR di SQL per raggiungere lo stesso obiettivo ( stackoverflow.com/questions/172735/… ).
Devinbost,

@bostIT Grazie per l'aggiunta. Rif. Per System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
h3xStream

91

Risposta : NO

Ecco perché ... Penso che un motivo chiave per aver memorizzato i proc in un database sia che stai eseguendo il codice SP nello stesso processo del motore SQL. Questo ha senso per i motori di database progettati per funzionare come un servizio connesso in rete ma l'imperativo per SQLite è molto meno dato che viene eseguito come una DLL nel processo dell'applicazione anziché in un processo del motore SQL separato. Quindi ha più senso implementare tutta la tua logica aziendale, incluso quello che sarebbe stato il codice SP nella lingua host.

Puoi comunque estendere SQLite con le tue funzioni definite dall'utente nella lingua host (PHP, Python, Perl, C #, Javascript , Ruby ecc.). È quindi possibile utilizzare queste funzioni personalizzate come parte di qualsiasi selezione / aggiornamento / inserimento / eliminazione di SQLite. L'ho fatto in C # usando DevArt's SQLite per implementare l'hash delle password.


16
Per chiarire ... Non sto dicendo che non vi è alcun motivo per implementare SP in SQLite - solo una ragione molto meno che in altri motori DB.
Tony O'Hagan,

4
Il motivo principale per cui sono state memorizzate le procedure è prevenire l'iniezione SQL. Vi sono tuttavia molte altre ragioni. Ad esempio, essere in grado di condividere le query pertinenti inserendole nel file sqlite. Non c'è assolutamente alcuna differenza tra una query standard che viene eseguita nel contesto di SQL Engine e la selezione di un SP. Entrambi sono in ESECUZIONE su SQL ENGINE.
Dan,

4
@Dan In primo luogo, SP esisteva molto prima che fosse stata pensata l'iniezione di SQL. Migliaia di app basate su SQL sono state create senza di esse e sono sicure contro questo attacco. Ho anche rivisto in codice SP non sicuri che sono vulnerabili all'iniezione SQL (in genere basata su SQL dinamico). Quindi no, non è questo il motivo principale. Ci sono molti altri modi per prevenire questo attacco più in alto nello stack.
Tony O'Hagan,

3
@Dan La maggior parte dei motori SQL sono client / server (NON SQLite!). Per questi, le prestazioni sono un problema chiave quando si decide dove collocare la propria logica aziendale. L'esecuzione della logica di business, sia essa una query o un codice condizionale o interattivo all'interno di un SP nel motore SQL può (1) migliorare le prestazioni di recupero dei dati, (2) ridurre il traffico di rete (3) ridurre l'utilizzo della memoria a livello di app (4) piani di esecuzione della query nella cache (precompilati SP). La maggior parte degli sviluppatori di app preferisce spostare la propria logica di business al di fuori del motore SQL (ovviamente non le query!). Per SQLite questo è meno di un imperativo in quanto non supporta client / server.
Tony O'Hagan,

Grazie Tony. Mi chiedevo perché SQLite non abbia procedure ma abbia funzioni integrate ( sqlite.org/lang_corefunc.html )? È corretto che per RDBMS client-server come postgresql, sia le funzioni che le procedure siano archiviate sul lato server? Poiché SQLite è privo di server, se SQLite non ha procedure, quindi per lo stesso motivo, non dovrebbe avere nemmeno funzioni?
Tim

17

Se sei ancora interessato, Chris Wolf ha realizzato un prototipo di implementazione di SQLite con Stored Procedures. Puoi trovare i dettagli nel suo post sul blog: Aggiunta di stored procedure a SQLite


5
L'articolo è morto ora, ma il progetto è su github.com/wolfch/sqlite-3.7.3.p1 . Il file readme implica che questo non è pronto per la produzione, né per la sperimentazione. Sembra che sia più una prova di concetto.
pqsk,

7

Tuttavia, è possibile simularlo usando una tabella dedicata, chiamata per il tuo fake-sp, con un trigger AFTER INSERT. Le righe della tabella dedicate contengono i parametri per il tuo falso sp, e se ha bisogno di restituire risultati puoi avere una seconda tabella (poss. Temp) (con il nome relativo al falso-sp) per contenere quei risultati. Richiederebbe due query: la prima per INSERIRE i dati nella tabella fake-sp-trigger e la seconda per SELEZIONARE dalla tabella fake-sp-results, che potrebbe essere vuota o avere un campo di messaggio se qualcosa andasse storto .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.