MySQL 5 - Vorteile von Stored Procedures
0 
dedlfix
0 0
MySQL 5 - Vorteile von Stored Procedures
Hallo.
Was bringen einem Stored Procedures?
Ist es schneller?
Weil wenn ja - sollte man doch so ziemlich das ganze Projekt mit Stored Procedures erstellen oder?
Gruß,
Goi
-
echo $begrüßung;
Was bringen einem Stored Procedures?
Das was einem ein programmierbarer Ablauf bringen kann. SELECT und Konsorten führen ja nur eine begrenzte Aufgabe aus. Stored Procedures können komplexe Programme sein.
Ist es schneller?
Schneller als was? Wenn Roundtrips zwischen Client und Server entfallen, entfällt natürlich auch die dafür verbrauchte Zeit. Der fachlicherseits notwendige Datentransport bleibt davon unberührt.
Weil wenn ja - sollte man doch so ziemlich das ganze Projekt mit Stored Procedures erstellen oder?
Man sollte sie dann einsetzen, wenn man ihre Möglichkeiten kennt und findet, dass ein bestimmtes Problem sich am besten damit lösen lässt.
Wenn du mit einfachen RUDI-Operationen[*] auskommst, solltest du dabei bleiben. Mehr Code in Form von zusätzlichen SPs benötigt auch mehr Ressourcen.
[*] Read, Update, Delete, Insert
echo "$verabschiedung $name";
-
Das was einem ein programmierbarer Ablauf bringen kann. SELECT und Konsorten führen ja nur eine begrenzte Aufgabe aus. Stored Procedures können komplexe Programme sein.
Komplex sehe ich immer sehr relativ. Es sind halt z.B. Queries mit JOINS und Mehrfach-JOINS. Das ich ein "SELECT user FROM users WHERE id ='".intval($id)."'" nicht als SP ablager, war mir schon klar.
»» Ist es schneller?
Schneller als diese größeren Queries welche in mehr als X(was empfiehlst du?) Tabellen operieren.
Schneller als was? Wenn Roundtrips zwischen Client und Server entfallen, entfällt natürlich auch die dafür verbrauchte Zeit.
Aber sie entfallen doch eigentlich nicht oder? Ich mein ich muss immer noch der DB sagen tue dies oder das. Okay - der Query ist kürzer.
Der fachlicherseits notwendige Datentransport bleibt davon unberührt.
Das ist klar.
Gruß,
goi
-
echo $begrüßung;
Komplex sehe ich immer sehr relativ. Es sind halt z.B. Queries mit JOINS und Mehrfach-JOINS. Das ich ein "SELECT user FROM users WHERE id ='".intval($id)."'" nicht als SP ablager, war mir schon klar.
Queries mit JOINS und Mehrfach-JOINS sind im Prinzip "nur einfache Abfragen". Vielleicht verwechselst du Stored Procedures mit Prepared Statements - jedenfalls sind Stored Procedures dann angebracht, wenn beispielsweise die Abfrage so komplex ist, dass eine oder mehrere temporäre Tabellen benötigt werden, die in mehreren Schritten erstellt und/oder durchgerechnet werden sollen. Stored Functions (ein Geschwist[*] von SPs) eignen sich, wenn etwas berechnet werden soll, was nicht mehr in ein Subselect passt. Also mehrstufige Abläufe, die nicht in ein Statement passen.
» » Ist es schneller?
Schneller als diese größeren Queries welche in mehr als X(was empfiehlst du?) Tabellen operieren.Da der Aufwand, der eine SP rechtfertigt, größer ist als eine einzelne einfache oder komplizierte Abfrage, kann das Ergebnis als solches nicht schneller sein. Es kann nur im Vergleich zu vorher schneller werden, wenn die notwendigen Einzelschritte zur Erfüllung einer Aufgabe bisher zwischen Client und Server hin- und hergereicht wurden.
» Schneller als was? Wenn Roundtrips zwischen Client und Server entfallen, entfällt natürlich auch die dafür verbrauchte Zeit.
Aber sie entfallen doch eigentlich nicht oder? Ich mein ich muss immer noch der DB sagen tue dies oder das. Okay - der Query ist kürzer.Eben. Der fachliche Aufwand bleibt erhalten. Er kann sich eventuell verringern, wenn man mit einer SP einen anderen, einfacheren Weg gehen kann als die vorherige Lösung.
[*] oder wie ist hier die Einzahl?
echo "$verabschiedung $name";
-
Hi!
ein Geschwist[*]
[*] oder wie ist hier die Einzahl?
Ich hätte ja nicht geglaubt, dass es überhaupt eine gibt, aber "das Geschwister" ist offenbar richtig...
Gruß
Bernhard
-
-
-
-
Hello,
Was bringen einem Stored Procedures?
Ich denke, es ist auch eine Frage der Kapselung.
Du kannst komplexe Abfragen per Stored Procedure durchführen lassen.
Der Client (seine API, PHP) benötigt auf die beteiligten Tabellen keinen Zugriff.Das ermöglicht Dir z.B., ein "Insert on Select" durchführen zu lassen, also dir zu merken, welcher Client wann welche vorbereitete Abfrage in Anspruch genommen hat. Es kann so niemand an die Daten heran, ohne dass dies registriert wird. Auch vertikale Zugriffsrechte lassen sich so abbilden, ohne dass sie umgangen werden können.
Das Gleiche gilt für Kern-Geschäftsregeln, also solche, die immer beachtet werden müssen.
Wenn Du die über Trigger und Stored Procedures verdrahtest, können sie nicht vergessen und nicht umgangen werden.Die variable Logik gehört dagegen sicherlich ins steuernde Programm.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
und weil wir hier alle Häppchen beisteuern...
Ist es schneller?
potenziell ja. Sofern du deine SQL-Statements als Strings übergibst ist es realistisch/denkbar, dass die Datenbank jedes Mal ein "neues" Statement sieht, d.h. es wird analysiert und durch den Optimizer geschickt, Indizes gesucht, was alles dazu gehört. Die Stored Procedure ist fix in der Datenbank, sie kann einmalig analysiert und der optimale Zugriffspfad hinterlegt werden.
MfG
Rouven--
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Buy when there's blood running in the street and sell when everyone is pounding at your door, clawing to own your equities -- Wisdom on Wallstreet