Wie der titel schon sagt geht es um die Frage welche Vor- und Nachteile prepared statements gegenüber stored procedures haben.
Bei beiden wird ein SQL-Statement vor Ausführung kompiliert, so das bei Ausführung schon für die DB aufbereiteter Code vorliegt.
Das bedeutet zum Einen ein Performancegewinn, zum Anderen ein Sicherheitsgewinn, da eine SQL injection in eine schon kompilierte Abfrage kaum möglich ist.
Wo jetzt liegen aber die Vorzüge der einen Technik gegenüber der Anderen?
Für einen entsprechenden, kleinen Vergleich wäre ich dankbar.
Folgender Text orientiert sich an der Sicht eines Javaprogramms:
bei stored procedures bist du in der Lage Datenbankfunktionen auszuführen und die Rückgabewerte derer zu bekommen. Mit einem Prepared Statement kannst du das nicht. Wenn du also ein einfaches Select/Update/Insert machen möchtest reicht dir eine PS. Möchtest du eine Funktion auf der DB aufrufen, nimm SP.
Weiterer Vorteil von Stored Procedures ist: Für Änderungen und Erweiterungen ist in vielen Fällen durch SPs keine Anpassung an der aufrufenden Anwendung notwendig. Wenn die Statements im Code stehen schon.
Das setzt natürlich voraus, dass die Aufrufparameter und Rückgabewerte der Stored Procedure gleich bleiben...
Ich bevorzuge SQL-Code in Prepared Statements. Und zwar aus den folgenden Gründen:
All meine Logik ist an einem Platz, im Sourcecode. Ich muss nicht auf Datenbanken rumhühnern und den Source von irgendwelchen Stored Procedures zusammensuchen.
Weil alles an einem Platz ist, lässt es sich auch leichter versionieren. Wenn ich ein Rollback zu einem gewissen Datum mache, kann ich mir sicher sein, dass die Datenbank auch den Code ausführt, der zu der entsprechenden Version gehört.
Last but not least: Eine Datenbank soll gefälligst Daten speichern. Das kann sie, und das kann sie gut, denn dafür ist sie da. Sämtliche Evaluierungen, Berechnungen und Entscheidungen (kurz: Logik) gehören einfach nicht in die Datenbank, sondern in die Applikation.
Das ist ziemlich kurzsichtig gedacht. Solange es EINE Applikation zu EINER Datenbank gibt funktioniert das auch. Sobald es aber in größeren Projekten mehrere Applikationen (z.B. die Inhouse-Warenwirtschaft und gleichzeitig auch die Web-Vertriebssoftware) gibt, die auf ein und diesselbe DB (oder Teile davon) zugreifen ist es durchaus sinnvoll gemeinsam genutzte Logik in die DB zu verlagern, um nicht redundanten Code Pflegen und konsistent halten zu müssen.
Logik in der Datenbank hat zur Folge, dass du bei einem Update der Logik (Veränderung der Input-/Output-Parameter) sämtliche Clients auf einmal updaten musst, was meiner Erfahrung nach zu größeren Problemen führt als die Codeduplikation.
Bei redundantem Code mußt du wohl nicht alle Clients auf einmal ändern wenn sich die zugrundeliegende Logik ändert!? Das Chaos möchte ich nicht erleben, wenn die Warenwirtschaft schon nach neuen Regeln die DB beackert während der Vertriebler im Web gleichzeitig noch mit den alten Regeln darauf zugreift ;).
Nein, weil sich die Logik im Client ändert, kann man jeden Client für sich alleine updaten. Klar, doof ist’s, wenn sich das zugrunde liegende Datenmodell substanziell verändert.
Es kommt doch auch immer ganz drauf an was man machen möchte. Wir haben einige SPs die wir benutzen, weil es über PS viel zu umständlich, und auch durch die Mengen an Daten und Operationen, viel zu zeitintensiv wird, als wenn man sämtliche berechnungen direkt auf der DB laufen lässt. Also es gibt für beides eine Daseinsberechtigung
Dazu kommt natürlich auch nocht das ich für die Ausführund der PS je nach Typ der Abfrage die entsprechenden Userrechte brauche. Arbeite ich mit SPs kann ich einen User nehmen der ausschliesslich die Rechte zum Ausführen von SPs hat - und habe damit einen Angriffsweg weniger auf die DB.
Ich klugscheiße ja wieder mal gerne. Dies ist keine Forensoftware. Antworte also bitte nicht selbst auf deine Fragen, weil im Normalfall durch Up-/Downvotes der Antworten die Reihenfolge nicht erhalten bleibt. Das wäre ein Fall für einen Kommentar.
Wobei der größere Teil der aussage durchaus eine Antwort auf meine eigene Frage ist, mir nur leider zu spät eingefallen ist als das ich sie noch mit in die Frage hätte aufnehmen wollen.
Dann werd ich auch mal klugscheißen :) Es gibt hier ein Abzeichen "Autodidakt" = Eigene Frage beantwortet, die mindestens 3 Mal positiv bewertet wurde. Auch wenns in diesem Fall vielleicht anders liegt, ist das beantworten eigener Fragen offensichtlich hier doch erwünscht. ;)
nichtsdestotrotz hat er sich in seiner antwort auf meine antwort bezogen. also hätte er den teil, der an mich ging als kommentar unter meine antwort setzen "müssen" und den teil, der quasi eine eigene antwort war in eine antwort verpacken müssen :)
Vielen Dank schonmal für diesen Hinweis.