Criando procedimento armazenado e SQLite?

181

De alguma forma, é possível criar um procedimento armazenado ao usar o SQLite?

sqlite stored-procedures

— grady
fonte

217

O SQLite teve que sacrificar outras características que algumas pessoas consideram úteis, como alta simultaneidade, controle de acesso refinado, um rico conjunto de funções internas , procedimentos armazenados , recursos esotéricos da linguagem SQL, extensões XML e / ou Java, ou escalabilidade peta-byte, e assim por diante

Fonte: Usos apropriados para SQLite

— h3xStream
fonte

3

Você pode usar o equivalente SQLite das funções SQL CLR para atingir o mesmo objetivo ( stackoverflow.com/questions/172735/… ).

— devinbost

Obrigado pela adição. Ref para System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki

— h3xStream

91

Resposta : NÃO

Eis o porquê ... Eu acho que uma das principais razões para armazenar procs em um banco de dados é que você está executando o código SP no mesmo processo que o mecanismo SQL. Isso faz sentido para os mecanismos de banco de dados projetados para funcionar como um serviço conectado à rede, mas o imperativo para o SQLite é muito menos, pois ele é executado como uma DLL no processo do aplicativo e não em um processo separado do mecanismo do SQL. Portanto, faz mais sentido implementar toda a lógica de negócios, incluindo o que seria o código SP no idioma do host.

No entanto, você pode estender o SQLite com suas próprias funções definidas pelo usuário na linguagem host (PHP, Python, Perl, C #, Javascript , Ruby etc.). Você pode usar essas funções personalizadas como parte de qualquer seleção / atualização / inserção / exclusão do SQLite. Eu fiz isso em c # usando o SQLite do DevArt para implementar o hash de senha.

— Tony O'Hagan
fonte

16

Para esclarecer ... Não estou dizendo que NÃO há razão para implementar SPs no SQLite - apenas muito menos razão do que em outros mecanismos de banco de dados.

— Tony O'Hagan

4

O principal motivo para ter procedimentos armazenados é impedir a injeção de SQL. Existem muitas outras razões, no entanto. Por exemplo, poder compartilhar as consultas relevantes, incorporando-as ao arquivo sqlite. Não há absolutamente nenhuma diferença entre uma consulta padrão que é executada no contexto do mecanismo SQL e a seleção de um SP. Ambos estão executando no SQL ENGINE.

— Dan

4

@ Dan Em primeiro lugar, os SPs existiam muito antes de se pensar na injeção de SQL. Milhares de aplicativos baseados em SQL foram criados sem eles, seguros contra esse ataque. Também analisei SPs inseguros que são vulneráveis à injeção de SQL (normalmente baseados em SQL dinâmico). Portanto, não, não é este o principal motivo. Existem muitas outras maneiras de impedir esse ataque ainda mais na pilha.

— Tony O'Hagan

3

@ Dan A maioria dos mecanismos SQL é cliente / servidor (NÃO SQLite!). Para esses, o desempenho é uma questão importante ao decidir onde colocar sua lógica de negócios. A execução da lógica de negócios, seja consulta OU código interativo OU condicional dentro de um SP no mecanismo SQL, pode (1) melhorar o desempenho da recuperação de dados, (2) reduzir o tráfego de rede (3) reduzir o uso de memória da camada de aplicativo (4) planos de execução de consulta em cache (pré-compilados SPs). A maioria dos desenvolvedores de aplicativos prefere mover parte de sua lógica de negócios para fora do mecanismo SQL (obviamente, não as consultas!). Para o SQLite, isso é menos imperativo, pois não suporta cliente / servidor.

— Tony O'Hagan

Obrigado, Tony. Fiquei me perguntando por que SQLite não tem procedimentos, mas tem funções internas ( sqlite.org/lang_corefunc.html )? É correto que, para RDBMS cliente-servidor, como o postgresql, ambas as funções e procedimentos sejam armazenados no lado do servidor? Como o SQLite não possui servidor, se o SQLite não possui procedimentos, pelo mesmo motivo, também não deveria ter funções?

— Tim

17

Se você ainda estiver interessado, Chris Wolf fez uma implementação de protótipo do SQLite com procedimentos armazenados. Você pode encontrar os detalhes em sua postagem no blog: Adicionando procedimentos armazenados ao SQLite

— histórico
fonte

5

O artigo está morto agora, mas o projeto está em github.com/wolfch/sqlite-3.7.3.p1 . O arquivo leia-me implica que isso não está pronto para produção nem para experimentação. Parece que é mais uma prova de conceito.

— Pqsk 13/05

7

No entanto, é possível falsificá-lo usando uma tabela dedicada, nomeada para o seu fake-sp, com um gatilho AFTER INSERT. As linhas da tabela dedicada contêm os parâmetros para o seu sp falso, e se precisar retornar resultados, você pode ter uma segunda tabela (poss. Temp) (com nome relacionado ao fake-sp) para conter esses resultados. Exigiria duas consultas: primeiro para inserir dados na tabela fake-sp-trigger e a segunda para SELECT da tabela fake-sp-results, que poderia estar vazia ou ter um campo de mensagem se algo desse errado. .

— slashmais
fonte