Est-il possible de créer une procédure stockée en utilisant SQLite ?
Vous pouvez utiliser l'équivalent SQLite des fonctions SQL CLR pour atteindre le même objectif ( stackoverflow.com/questions/172735/ ).
Réponses
Trop de publicités?SQLite a dû sacrifier d'autres caractéristiques que certaines personnes trouvent utiles, comme une forte concurrence, un contrôle d'accès à grain fin, un riche ensemble de fonctions intégrées, procédures stockées les fonctionnalités ésotériques du langage SQL, les extensions XML et/ou Java, l'extensibilité en téra ou pétaoctets, etc.
Source : Utilisations appropriées de SQLite
@bostIT Merci pour l'ajout. Réf. pour System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
Tony O'Hagan
Points
1330
Réponse : : NON
Voici pourquoi ... Je pense qu'une raison clé pour avoir des procs stockés dans une base de données est que vous exécutez le 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 bien moindre étant donné qu'il s'exécute comme une DLL dans votre processus d'application plutôt que dans un processus séparé du moteur SQL. Il est donc plus logique d'implémenter toute votre logique commerciale, 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 opération de sélection/mise à jour/insertion/suppression SQLite. J'ai fait ceci en C# en utilisant SQLite de DevArt pour implémenter le hachage de mot de passe.
Pour clarifier... Je ne dis pas qu'il n'y a AUCUNE raison d'implémenter des SPs dans SQLite - juste beaucoup moins de raisons que dans d'autres moteurs de BD.
La principale raison d'avoir des procédures stockées est de se prémunir contre les injections SQL. Il existe cependant de nombreuses autres raisons. Par exemple, la possibilité 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'une procédure stockée. Les deux s'exécutent sur le moteur SQL.
@Dan Tout d'abord, les SP existaient bien avant que l'on pense à l'injection SQL. Des milliers d'applications basées sur SQL ont été construites sans eux et sont protégées contre cette attaque. J'ai également passé en revue le code de SP non sécurisés qui sont vulnérables à l'injection SQL (généralement basés sur le SQL dynamique). Donc non, je ne pense pas que ce soit une raison principale. Il y a beaucoup d'autres moyens d'empêcher cette attaque en amont.
slashmais
Points
3924
Pourtant, il est possible de le simuler en utilisant une table dédiée, nommée pour votre faux-sp, avec un déclencheur AFTER INSERT. Les lignes de la table dédiée contiennent les paramètres de votre faux-sp, et s'il doit renvoyer des résultats, vous pouvez avoir une deuxième table (éventuellement temporaire) (avec un nom lié au faux-sp) pour contenir ces résultats. Cela nécessiterait deux requêtes : la première pour INSERTER des données dans la table fake-sp-trigger, et la seconde pour SELECTIONNER dans la table fake-sp-results, qui pourrait être vide, ou avoir un champ de message si quelque chose ne va pas.
torial
Points
9883
Si vous êtes toujours intéressé, Chris Wolf a réalisé un prototype d'implémentation de SQLite avec des procédures stockées. Vous pouvez trouver les détails sur son blog : Ajouter des procédures stockées à SQLite
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 qu'il s'agisse plutôt d'une preuve de concept.
Anton Gogolev
Points
59794
SQLite n'a pas de sprocs .
- Réponses précédentes
- Plus de réponses
