Gespeicherte Prozedur und SQLite erstellen?

181

Ist es irgendwie möglich, eine gespeicherte Prozedur zu erstellen, wenn SQLite verwendet wird?

sqlite stored-procedures

— grady
quelle

216

SQLite musste andere Eigenschaften opfern, die einige Leute für nützlich halten, wie hohe Parallelität, fein abgestimmte Zugriffskontrolle, eine Vielzahl integrierter Funktionen, gespeicherte Prozeduren , esoterische SQL -Sprachfunktionen , XML- und / oder Java-Erweiterungen, tera- oder Peta-Byte-Skalierbarkeit und so weiter

Quelle: Geeignete Verwendungen für SQLite

— h3xStream
quelle

3

Sie können das SQLite-Äquivalent von SQL CLR-Funktionen verwenden, um dasselbe Ziel zu erreichen ( stackoverflow.com/questions/172735/… ).

— Devinbost

@bostIT Danke für den Zusatz. Ref für System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki

— h3xStream

91

Antwort : NEIN

Hier ist der Grund ... Ich denke, ein Hauptgrund für das Speichern von Prozessen in einer Datenbank ist, dass Sie SP-Code im selben Prozess wie die SQL-Engine ausführen. Dies ist für Datenbankmodule sinnvoll, die als netzwerkverbundener Dienst konzipiert sind. Für SQLite ist es jedoch weitaus weniger wichtig, dass es in Ihrem Anwendungsprozess als DLL ausgeführt wird und nicht in einem separaten SQL-Modulprozess. Daher ist es sinnvoller, Ihre gesamte Geschäftslogik zu implementieren, einschließlich des SP-Codes in der Hostsprache.

Sie können SQLite jedoch mit Ihren eigenen benutzerdefinierten Funktionen in der Hostsprache (PHP, Python, Perl, C #, Javascript , Ruby usw.) erweitern. Sie können diese benutzerdefinierten Funktionen dann als Teil jeder SQLite-Auswahl / Aktualisierung / Einfügung / Löschung verwenden. Ich habe dies in C # mit DevArts SQLite getan , um das Passwort-Hashing zu implementieren.

— Tony O'Hagan
quelle

16

Zur Verdeutlichung ... Ich sage nicht, dass es KEINEN Grund gibt, SPs in SQLite zu implementieren - nur viel weniger Grund als in anderen DB-Engines.

— Tony O'Hagan

4

Der Hauptgrund für gespeicherte Prozeduren ist die Verhinderung von SQL Injection. Es gibt jedoch viele andere Gründe. Zum Beispiel können Sie die relevanten Abfragen freigeben, indem Sie sie in die SQLite-Datei einbetten. Es gibt absolut keinen Unterschied zwischen einer Standardabfrage, die im Kontext der SQL Engine ausgeführt wird, und der Auswahl eines SP. Sie laufen beide auf der SQL ENGINE.

— Dan

4

@Dan Erstens existierten SPs lange bevor an SQL Injection gedacht wurde. Tausende von SQL-basierten Apps wurden ohne diese erstellt, die vor diesem Angriff sicher sind. Ich habe auch unsichere SPs überprüft, die für SQL-Injection anfällig sind (normalerweise basierend auf dynamischem SQL). Also nein, ich weiß nicht, das ist ein Hauptgrund. Es gibt viele andere Möglichkeiten, um diesen Angriff weiter oben im Stapel zu verhindern.

— Tony O'Hagan

3

@Dan Die meisten SQL-Engines sind Client / Server (NICHT SQLite!). Für diese ist die Leistung ein zentrales Problem bei der Entscheidung, wo Ihre Geschäftslogik abgelegt werden soll. Das Ausführen von Geschäftslogik, sei es Abfrage ODER interativer ODER bedingter Code innerhalb eines SP in der SQL-Engine, kann (1) die Leistung beim Abrufen von Daten verbessern, (2) den Netzwerkverkehr reduzieren (3) die Speichernutzung auf App-Ebene reduzieren (4) Ausführungspläne für Cache-Abfragen (vorkompiliert) SPs). Die meisten App-Entwickler ziehen es vor, einen Teil ihrer Geschäftslogik außerhalb der SQL-Engine zu verschieben (offensichtlich nicht die Abfragen!). Für SQLite ist dies weniger wichtig, da Client / Server nicht unterstützt werden.

— Tony O'Hagan

Danke, Tony. Ich habe mich gefragt, warum SQLite keine Prozeduren hat, aber eingebaute Funktionen ( sqlite.org/lang_corefunc.html ). Ist es richtig, dass für Client-Server-RDBMS wie postgresql sowohl Funktionen als auch Prozeduren auf der Serverseite gespeichert werden? Da SQLite ohne Server ist und SQLite keine Prozeduren hat, sollte es aus demselben Grund auch keine Funktionen haben?

— Tim

17

Wenn Sie immer noch interessiert sind, hat Chris Wolf einen Prototyp der Implementierung von SQLite mit gespeicherten Prozeduren erstellt. Die Details finden Sie in seinem Blogbeitrag: Hinzufügen gespeicherter Prozeduren zu SQLite

— torial
quelle

5

Artikel ist jetzt tot, aber das Projekt ist unter github.com/wolfch/sqlite-3.7.3.p1 . Die Readme-Datei impliziert, dass dies weder produktionsbereit noch experimentierfreudig ist. Es scheint eher ein Proof of Concept zu sein.

— pqsk

7

Dennoch ist es möglich , zu fälschen es eine eigene Tabelle mit dem Namen für Ihren fake-sp, mit einem INSERT - Trigger nach. Die dedizierten Tabellenzeilen enthalten die Parameter für Ihre gefälschte SP. Wenn Ergebnisse zurückgegeben werden müssen, können Sie eine zweite (möglicherweise temporäre) Tabelle (mit dem Namen der gefälschten SP) verwenden, um diese Ergebnisse zu enthalten. Es wären zwei Abfragen erforderlich: erstens Daten in die Fake-SP-Trigger-Tabelle EINFÜGEN und zweitens SELECT aus der Fake-SP-Ergebnistabelle, die leer sein könnte, oder ein Nachrichtenfeld haben, wenn etwas schief geht .

— Slashmais
quelle