Créer une procédure stockée et SQLite?

181

Est-il possible d'une manière ou d'une autre de créer une procédure stockée lors de l'utilisation de SQLite?

sqlite stored-procedures

— grady
source

217

SQLite a dû sacrifier d'autres caractéristiques que certaines personnes trouvent utiles, telles qu'une concurrence élevée, un contrôle d'accès précis, un riche ensemble de fonctions intégrées, des procédures stockées , des fonctionnalités de langage SQL ésotérique, des extensions XML et / ou Java, tera- ou évolutivité en péta-octet, etc.

Source: Utilisations appropriées pour SQLite

— h3xStream
source

3

Vous pouvez utiliser l'équivalent SQLite des fonctions SQL CLR pour atteindre le même objectif ( stackoverflow.com/questions/172735/… ).

— devinbost

@bostIT Merci pour l'ajout. Réf pour System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki

— h3xStream

91

Réponse : NON

Voici pourquoi ... Je pense qu'une raison clé pour avoir stocké des procs dans une base de données est que vous exécutez du code SP dans le même processus que le moteur SQL. Cela a du sens pour les moteurs de base de données conçus pour fonctionner comme un service connecté au réseau, mais l'impératif pour SQLite est beaucoup moins important étant donné qu'il s'exécute en tant que DLL dans votre processus d'application plutôt que dans un processus de moteur SQL séparé. Il est donc plus logique d'implémenter toute votre logique métier, y compris ce qui aurait été du code SP dans le langage hôte.

Vous pouvez cependant étendre SQLite avec vos propres fonctions définies par l'utilisateur dans le langage hôte (PHP, Python, Perl, C #, Javascript , Ruby, etc.). Vous pouvez ensuite utiliser ces fonctions personnalisées dans le cadre de toute sélection / mise à jour / insertion / suppression de SQLite. J'ai fait cela en C # en utilisant SQLite de DevArt pour implémenter le hachage de mot de passe.

— Tony O'Hagan
source

16

Pour clarifier ... je ne dis pas qu'il n'y a AUCUNE raison d'implémenter des SP dans SQLite - juste beaucoup moins de raison que dans d'autres moteurs de base de données.

— Tony O'Hagan

4

La raison CLÉ pour avoir des procédures stockées est d'éviter l'injection SQL. Il existe cependant de nombreuses autres raisons. Par exemple, être capable de partager les requêtes pertinentes en les intégrant dans le fichier sqlite. Il n'y a absolument aucune différence entre une requête standard qui s'exécute dans le contexte du moteur SQL et la sélection d'un SP. Ils fonctionnent tous les deux sur le MOTEUR SQL.

— Dan le

4

@Dan Premièrement, les SP existaient bien avant que l'injection SQL n'ait été envisagée. Des milliers d'applications basées sur SQL ont été créées sans elles qui sont sûres contre cette attaque. J'ai également passé en revue le code des SP non sécurisés qui sont vulnérables à l'injection SQL (généralement basée sur SQL dynamique). Donc non, je ne sais pas, c'est la raison principale. Il existe de nombreuses autres façons d'empêcher cette attaque plus haut dans la pile.

— Tony O'Hagan

3

@Dan La plupart des moteurs SQL sont client / serveur (PAS SQLite!). Pour ceux-ci, les performances sont un problème clé pour décider où placer votre logique métier. L'exécution de la logique métier, que ce soit une requête OU un code interatif OU conditionnel à l'intérieur d'un SP dans le moteur SQL peut (1) améliorer les performances de récupération des données, (2) réduire le trafic réseau (3) réduire l'utilisation de la mémoire de la couche application (4) plans d'exécution des requêtes de cache (précompilés SP). La plupart des développeurs d'applications préfèrent déplacer une partie de leur logique métier en dehors du moteur SQL (évidemment pas les requêtes!). Pour SQLite, c'est moins impératif car il ne prend pas en charge le client / serveur.

— Tony O'Hagan

Merci, Tony. Je me demandais pourquoi SQLite n'a pas de procédures mais a des fonctions intégrées ( sqlite.org/lang_corefunc.html )? Est-il exact que pour le SGBDR client-serveur tel que postgresql, les fonctions et les procédures sont stockées côté serveur? Puisque SQLite est sans serveur, si SQLite n'a pas de procédures, alors pour la même raison, ne devrait-il pas non plus avoir de fonctions?

— Tim

17

Si vous êtes toujours intéressé, Chris Wolf a réalisé une implémentation prototype de SQLite avec des procédures stockées. Vous pouvez trouver les détails sur son article de blog: Ajouter des procédures stockées à SQLite

— torial
source

5

L'article est mort maintenant, mais le projet est à github.com/wolfch/sqlite-3.7.3.p1 . Le fichier readme implique que ce n'est pas prêt pour la production, ni pour l'expérimentation. Il semble que ce soit plus une preuve de concept.

— pqsk

7

Pourtant, il est possible de le simuler en utilisant une table dédiée, nommée d'après votre faux-sp, avec un déclencheur AFTER INSERT. Les lignes de table dédiées contiennent les paramètres de votre faux sp, et s'il a besoin de renvoyer des résultats, vous pouvez avoir une deuxième table (poss. Temp) (avec un nom lié au faux-sp) pour contenir ces résultats. Cela nécessiterait deux requêtes: d'abord pour INSÉRER les données dans la fake-sp-trigger-table, et la seconde pour SELECT à partir de la fake-sp-results-table, qui pourrait être vide, ou avoir un champ de message si quelque chose ne va pas .

— slashmais
source