nicht angemeldet
Wann lohnen sich stored procedures? (PostgreSQL)
Hey.
Ab wann lohnt es sich Stored Procedures / User defined Functions einzusetzen?
Es ist für die Datenbank doch immer schneller auf diese zuzugreifen als den Query jedes mal neu zu "parsen"(?)?
Warum also nicht möglichst jeden Query auslagern?
Bei meinem Projekt wären das allerdings mind. über 300 Queries die ich dort einlagern müsste. Macht das Sinn oder sollte ich nur die "großen" komplexeren dort abspeichern?
Lg, Phil
-
moin,
Macht das Sinn oder sollte ich nur die "großen" komplexeren dort abspeichern?
wie kommst du darauf, dass eine abfrage (reines sql) schneller ist, wenn sie als eine stored procedure gespeichert ist ?
Ilja
-
Macht das Sinn oder sollte ich nur die "großen" komplexeren dort abspeichern?
wie kommst du darauf, dass eine abfrage (reines sql) schneller ist, wenn sie als eine stored procedure gespeichert ist ?
Schrieb er doch: Weil die Prozedur schon durch den Parser gelaufen ist.
Das dürfte aber eher seltenst ins Gewicht fallen und so doch, sollte es die Möglichkeit geben, die ganze SQL-Anweisung einmalig durch den Parser vorbereiten zu lassen.
-
moin,
Das dürfte aber eher seltenst ins Gewicht fallen und so doch, sollte es die Möglichkeit geben, die ganze SQL-Anweisung einmalig durch den Parser vorbereiten zu lassen.
ich würde mal behaupten, dass reines sql schneller sein wird und wenn nicht, immer gleichschnell.
Ilja
-
ich würde mal behaupten, dass reines sql schneller sein wird und wenn nicht, immer gleichschnell.
Es ist doch reines SQL, nur es muss nicht mehr geparst werden da es in der Datenbank liegt. Es wird also nur noch die Funktion mit Parametern aufgerufen.
-
ich würde mal behaupten, dass reines sql schneller sein wird und wenn nicht, immer gleichschnell.
Es ist doch reines SQL, nur es muss nicht mehr geparst werden da es in der Datenbank liegt. Es wird also nur noch die Funktion mit Parametern aufgerufen.
Ähnlich wie ein Compilercache?
-
Es ist doch reines SQL, nur es muss nicht mehr geparst werden da es in der Datenbank liegt. Es wird also nur noch die Funktion mit Parametern aufgerufen.
soso, muss es nicht mehr...mal davon abgesehen, dass du kontextwechsel hast. ich bleibe bei meiner aussage, reines sql wird schneller oder mindestens gleichschnell sein.
Ilja
-
soso, muss es nicht mehr...mal davon abgesehen, dass du kontextwechsel hast. ich bleibe bei meiner aussage, reines sql wird schneller oder mindestens gleichschnell sein.
"Stored Procedures sind schnell. Sehr schnell. Und dies aus zwei Gründen. Jedes SQL-Statement muss vom SQL Server natürlich erst einmal auf gültige Syntax, Benutzung gültiger Objekte etc. überprüft – kurz: geparst – werden, ehe der Query Optimizer einen Ausführungsplan (welche Tabellen werden anhand welche Indexe durchsucht etc.) erstellen kann. "
-
"Stored Procedures sind schnell. Sehr schnell. Und dies aus zwei Gründen. Jedes SQL-Statement muss vom SQL Server natürlich erst einmal auf gültige Syntax, Benutzung gültiger Objekte etc. überprüft – kurz: geparst – werden, ehe der Query Optimizer einen Ausführungsplan (welche Tabellen werden anhand welche Indexe durchsucht etc.) erstellen kann. "
"Der zweite Grund für die gute Geschwindigkeit der Stored Procedures ist dies: Der SQL Server lädt die kompilierte Version aller Stored Procedures beim Start in den so genannten Procedurecache; also in den Arbeitsspeicher. Der ist nun ebenfalls bekanntermaßen schnell."
-
ich glaube, du verwechselst äpfel mit birnen. wir reden hier über stored procedures und functions im vergleich zu einer reinen SQL anweisung.
Ilja
-
-
-
-
-
-
-
-
Ab wann lohnt es sich Stored Procedures / User defined Functions einzusetzen?
Wenn man immer wiederkehrende Aufgaben nicht immer wieder eintippen will bzw. mehrere Leute die gleichen Aufgaben garantiert auf gleiche Weise erledigen sollen. Wenn man darüber hinaus dann noch von Triggern absieht, also Aufgaben, die die Datenbank bei Änderungen eigenständig erledigen soll: Ansonsten nicht.
-
Wenn man immer wiederkehrende Aufgaben nicht immer wieder eintippen will bzw. mehrere Leute die gleichen Aufgaben garantiert auf gleiche Weise erledigen sollen. Wenn man darüber hinaus dann noch von Triggern absieht, also Aufgaben, die die Datenbank bei Änderungen eigenständig erledigen soll: Ansonsten nicht.
Na wenn auf meiner Startseite News abgerufen werden Z.B. Dann ist das jedes mal der selbe Query nur mit einem anderen Parameter.
Also, user defined function oder nicht?Und was ist wenn ein User die Möglichkeit hat etwas zu voten.
Es ändern sich nur die Parameter, mehr nicht. User defined function?Lg, Phil
-
Hallo,
Na wenn auf meiner Startseite News abgerufen werden Z.B. Dann ist das jedes mal der selbe Query nur mit einem anderen Parameter.
Also, user defined function oder nicht?Nein. Wozu?
Und was ist wenn ein User die Möglichkeit hat etwas zu voten.
Es ändern sich nur die Parameter, mehr nicht. User defined function?Nein. Wozu?
Betreibst Du Mikrooptimierung?Freundliche Grüße
Vinzenz
-
Und was ist wenn ein User die Möglichkeit hat etwas zu voten.
Es ändern sich nur die Parameter, mehr nicht. User defined function?Nein. Wozu?
Performance.
Betreibst Du Mikrooptimierung?
Kleinvieh macht auch Mist.
-
Performance.
Kleinvieh macht auch Mist.du wirst wenn überhaupt nur langsamer werden....
Ilja
-
Performance.
Kleinvieh macht auch Mist.du wirst wenn überhaupt nur langsamer werden....
Warum?
-
-
Hallo,
Und was ist wenn ein User die Möglichkeit hat etwas zu voten.
Es ändern sich nur die Parameter, mehr nicht. User defined function?Nein. Wozu?
Performance.
Betreibst Du Mikrooptimierung?
Kleinvieh macht auch Mist.Ob das Kapseln von einfachen, billigen unkomplizierten SQL-Statements in SPs in *Deinem* Fall etwas bringt, das kannst *Du* mit *Deinen* Daten messen.
Typische Aufgabengebiete für SPs ist zum Beispiel die Abbildung von Geschäftslogik.
Freundliche Grüße
Vinzenz
-
-
-
Na wenn auf meiner Startseite News abgerufen werden Z.B. Dann ist das jedes mal der selbe Query nur mit einem anderen Parameter.
Also, user defined function oder nicht?Ich weiß jetzt, offen gesagt, nicht, wie du überhaupt bei einer simplen Abfrage à la 'select bla from fasel where x>$irgendwas' eine Funktion einsetzen willst.
Für sowas ist die genannte Möglichkeit, SQL-Abfragen vorzubereiten (MySQL-Kapitel dazu), die beste.
Du könntest davon abgesehen Ergebnisse auch selbst in einer Datei zwischenspeichern. Bei deinem Beispiel mit den Neuigkeiten würde es kaum ins Gewicht fallen, wenn du nur alle Minute oder gar alle fünf Minuten eine neue Datenbankabfrage machst. Ob das aber tatsächlich schneller ist, hängt von den Gegebenheiten ab – grundsätzlich müsste deine Datenbank schon sehr belastet sein.
-
-
-
Hallo,
Ab wann lohnt es sich Stored Procedures / User defined Functions einzusetzen?
wenn man sie benötigt.
Es ist für die Datenbank doch immer schneller auf diese zuzugreifen als den Query jedes mal neu zu "parsen"(?)?
[ ] Du hast schon von Prepared Statements gehört?
Freundliche Grüße
Vinzenz
-
Ab wann lohnt es sich Stored Procedures / User defined Functions einzusetzen?
wenn man sie benötigt.
Wann benötigt man diese?
Es ist für die Datenbank doch immer schneller auf diese zuzugreifen als den Query jedes mal neu zu "parsen"(?)?
[ ] Du hast schon von Prepared Statements gehört?
Ja, diese machen aber nur Sinn wenn ein und der selbe Query mehrfach nacheinander ausgeführt werden muss (innerhalb eines Scriptaufrufs).
-
-
h1,
Ab wann lohnt es sich Stored Procedures / User defined Functions
einzusetzen?
In einer Ich-AG lohnt sich das nicht. Anders hingegen sieht es in einer teamorientierten Entwicklungsumgebung aus. z.B. gäbe es das DB-Team und das Team was die Anwendungen schreibt. Das AW-Team hat dann den Kopf frei von DB-Abhängigkeiten im weiteren Sinne, die werden vom DB-Team erledigt. Mal ganz vereinfacht ausgedrückt. Letztendlich wird damit auch der Programmcode modularer und übersichtlicher. Programmierer werden austauschbar...
Hotti
--
Woran ich gerade arbeite: Hottisela. Es soll einen Pegel von 120 dB erzeugen.
-
In einer Ich-AG lohnt sich das nicht. Anders hingegen sieht es in einer teamorientierten Entwicklungsumgebung aus. z.B. gäbe es das DB-Team und das Team was die Anwendungen schreibt. Das AW-Team hat dann den Kopf frei von DB-Abhängigkeiten im weiteren Sinne, die werden vom DB-Team erledigt. Mal ganz vereinfacht ausgedrückt. Letztendlich wird damit auch der Programmcode modularer und übersichtlicher. Programmierer werden austauschbar...
Das Projekt ist größer, ein zweiter Programmierer wird in 2 Wochen eingestellt.
Mir geht es allerdings in erster Linie um Performance und wenn es nur eine hundertstel Sekunde schneller ist und minimal entlastet - tut es das?-
h1,
Das Projekt ist größer, ein zweiter Programmierer wird in 2 Wochen eingestellt.
Also mehr als ne Ich-AG...
Mir geht es allerdings in erster Linie um Performance und wenn es nur eine hundertstel Sekunde schneller ist und minimal entlastet - tut es das?
Diese Frage musst Du an das DB-Team richten ;-)
Ne, klar, im Ernst, für Deinen Fall lohnen sich SP bestimmt. Wg. der Performance haben die Experten schon Einiges geschrieben.
Hotti
--
Das Hottisela wird elektrisch betrieben. Aus erneuerbaren Energiequellen versteht sich...
-
-
-
Hallo,
Nachteile:
- wesentlich höherer Aufwand für:
- Planung
- Entwicklung
- Dokumentation
- Änderung
Vorteile:
- deutlich bessere Performance
- Integrieren von Logik
- bessere Trennung von Anwendungsschichten
- Schutz vor SQL Injection (bei Beachtung einiger Regeln)
- Sicherheit - Benutzerzugriff nur auf SP statt direkt auf Tabelle erlauben
Das wichtigste Argument gegen SP's ist der wesentlich höhere Aufwand. Wann es für dich sinnvoll ist mußt Du selber entscheiden. Dabei solltest Du auch an evtl. spätere Anpassungen der Tabellen denken, da dies eine Anpasssung der betroffenen SP's nach sich zieht.
MfG
-
Hallo,
Nachteile:
- wesentlich höherer Aufwand für:
- Planung
- Entwicklung
- Dokumentation
- Änderung
Vorteile:
- deutlich bessere Performance
- Integrieren von Logik
- bessere Trennung von Anwendungsschichten
- Schutz vor SQL Injection (bei Beachtung einiger Regeln)
- Sicherheit - Benutzerzugriff nur auf SP statt direkt auf Tabelle erlauben
Das das ist doch mal klar und deutlich.
Du sagst die Performance sei deutlich besser - jeder sagt was anderes. Allgemein lese ich aber auch das die Performance deutlich besser sei.
Die oben genannten Nachteile seien mal dahergestellt!
Lohnt es sich _alle_ Queries als SP zu speichern?Letztendlich ja theoretisch schon, denn jeder Query wird ein funken schneller ausgeführt oder?
Lg,
-
Hallo,
Lohnt es sich _alle_ Queries als SP zu speichern?
Letztendlich ja theoretisch schon, denn jeder Query wird ein funken schneller ausgeführt oder?
Theoretisch lohnt es sich. Ja.
MfG
-
moin,
Letztendlich ja theoretisch schon, denn jeder Query wird ein funken schneller ausgeführt oder?
Theoretisch lohnt es sich. Ja.und auf welcher theorie beruht das ?
Ilja
-
Hallo,
Theoretisch lohnt es sich. Ja.
und auf welcher theorie beruht das ?
"They are parsed and optimized when they are first executed, and a compiled version of the stored procedure remains in memory cache for later use. This means the stored procedure does not need to be reparsed and reoptimized with each use resulting in much faster execution times."
auf dieser Theorie http://msdn.microsoft.com/en-us/library/aa214299(v=SQL.80).aspx und auf eigenen Erfahrungen.
Ich habe noch nirgends gelesen, dass eine SP der Performance schadet, lasse mich aber gerne vom Gegenteil überzeugen.
MfG
-
Ich habe noch nirgends gelesen, dass eine SP der Performance schadet, lasse mich aber gerne vom Gegenteil überzeugen.
Ich auch nicht. Auch unter PostgreSQL haben sich größere Abfragen mit Joins, Subselects usw als schneller erwiesen.
Gut ist auch das man über den SQL Standard hinaus, Syntax verwenden kann die verschiedene Aufgaben die eigentlich später ausgeführt werden würden via z.B. PHP auf die DB verlagern kann. Das spart Zeit. -
"They are parsed and optimized when they are first executed, and a compiled version of the stored procedure remains in memory cache for later use. This means the stored procedure does not need to be reparsed and reoptimized with each use resulting in much faster execution times."
und was hat das bitte damit zu tun, was ich gesagt habe. unabhängig davon, ob eine stored procedure im cache liegt (was eine reine sql anweisung auch kann) und unabängig davon, dass die sp schon compiliert wurde, wird die sp engine die sql anweisung an die sql egine übergeben.
Ich habe noch nirgends gelesen, dass eine SP der Performance schadet, lasse mich aber gerne vom Gegenteil überzeugen.
tut sie, wenn du nur reines sql damit ausführst, dann hast du einen overhead
Ilja
-
Hallo,
und unabängig davon, dass die sp schon compiliert wurde, wird die sp engine die sql anweisung an die sql egine übergeben.
Wie kommst Du darauf?
Ich denke 'Parsen' und 'Kompilieren' schliesst auch die Datenbanksprache SQL ein!Ich kann die Diskussion auch nicht verstehen. Gib in der Suchmaschine Deiner Wahl 'stored procedure performance' ein und Du findest reichlich Aussagen dazu. Bitte poste doch mal die Links mit einem angegebenen Leistungsverlust bei der Nutzung einer SP!
Oder am besten testest du es selbst über ein paar 1000 Datensätze, einmal als String und einmal in einer SP, da sollten schon sehr deutliche Zeitunterschiede zutage treten.
MfG
-
moin,
Ich denke 'Parsen' und 'Kompilieren' schliesst auch die Datenbanksprache SQL ein!
das kann ja in vielen bereichen schon gar nicht gehen, alleine weil man dort dynamisches sql einsetzen kann, sprich SQL, dass erst zur laufzeit gebildet wird. wie soll ich das den vorher parsen ???
Ich kann die Diskussion auch nicht verstehen. Gib in der Suchmaschine Deiner Wahl 'stored procedure performance' ein und Du findest reichlich Aussagen dazu.
welche Links bitte ?
Bitte poste doch mal die Links mit einem angegebenen Leistungsverlust bei der Nutzung einer SP!
http://www.oracle.com/technology/tech/pl_sql/pdf/doing_sql_from_plsql.pdf
ab Ende Seite 6, Anfang seite 7 wird es interessant:
"Then, at run time, appropriate calls are made to parse, bind, and execute the
regular SQL statement."Ilja
-
Hallo Ilja,
nur ergänzend:
das kann ja in vielen bereichen schon gar nicht gehen, alleine weil man dort dynamisches sql einsetzen kann, sprich SQL, dass erst zur laufzeit gebildet wird. wie soll ich das den vorher parsen ???
sogar bei einem einfachen parametrisiertem Statement kann der Ausführungsplan der Abfrage von den vorhandenen Daten und dem Parameterwert abhängen, siehe http://linuxfinances.info/info/sqlqueries.html - und ist somit auch für eine SP erst zur Laufzeit ermittelbar.
Freundliche Grüße
Vinzenz
-
moin Vinzenz,
und ist somit auch für eine SP erst zur Laufzeit ermittelbar.
sehe ich ganz genauso, sprich wir haben den "normalen" SQL ablauf PLUS den overhead inklusive kontext wechsell durch die sp. das kann im besten falle nur gleich schnell sein (unterschied nicht messbar) oder eben langsamer...
Ilja
-
Hallo Ilja,
sehe ich ganz genauso, sprich wir haben den "normalen" SQL ablauf PLUS den overhead inklusive kontext wechsell durch die sp. das kann im besten falle nur gleich schnell sein (unterschied nicht messbar) oder eben langsamer...
es ist wie mit Joins, Subselects, UNIONS und anderem. Es gibt für alles Anwendungszwecke. Nichts davon ist ein Allheilmittel für alle Zwecke.
Freundliche Grüße
Vinzenz
-
moin Vinzenz,
es ist wie mit Joins, Subselects, UNIONS und anderem. Es gibt für alles Anwendungszwecke. Nichts davon ist ein Allheilmittel für alle Zwecke.
klar, ist alles fallabhängig und sp haben ihren sinn. performance-gewinn über sp für reines sql ist aber auszuschließen.
Ilja
-
Ich hab hier ein Buch:
Thomas Pfeiffer, Andreas Wenk, PostgreSQL 8.4 (Galileo Computing)
Dort schreibt man:
S. 225 Kapitel 5.2 Vorteile durch den Einsatz von User Defined FunctionsPerformance
"Der wohl wichtigste Aspekt [...] Performancegewinn [...]nicht jedes mal neu "geparsed" beziehungsweise "kompiliert" [...] verlgeichbar [...] Opcode-Cache in PHP."
-
"Der wohl wichtigste Aspekt [...] Performancegewinn [...]nicht jedes mal neu "geparsed" beziehungsweise "kompiliert" [...] verlgeichbar [...] Opcode-Cache in PHP."
ich habe mir letzte woche auch ein buch über datenbanken geholt, dort wollte man mir weiß machen, dass rdbms relational heißen, weil es beziehungen zwischen tabellen geben kann. aber vielleicht kannst du ja mal ein wenig mehr aus der entsprechenden stelle schreiben, mir ist nämlich noch nicht klar, welcher performance gewinn damit gemeint ist, gegenüber was genau.
mal grundsätzlich, wie stellt ihr euch das vor, ich parse ein sql in einer sp zu einer zeit von anno 1900 und der soll heute noch brauchbar sein ?
Ilja
-
-
-
Hi.
es ist wie mit Joins, Subselects, UNIONS und anderem. Es gibt für alles Anwendungszwecke. Nichts davon ist ein Allheilmittel für alle Zwecke.
Ich denke auch. Vielleicht aber gibt es den Performancevorteil genau dann wenn man wirklich sowas wie ne Nachrichtenseite hat und die letzten x Ergebnisse sollen angezeigt werden. Ein Query ohne Parameter. Dieser ist immer gleich, muss dann nur einmal verarbeitet werden und bleibt im Cache.
Ein normaler SQL-Query der im Cache liegt, speichert normalerweise nur das Ergebnis. Da dieses bei einer Newsseite über 4183674 Themen minütlich ändert, "cached"/optimiert man das, was man optimieren kann und das, indem man den Query nicht jedes mal neu parsten muss sondern einfach nur CALL XX und ende.
-
Ein normaler SQL-Query der im Cache liegt, speichert normalerweise nur das Ergebnis. Da dieses bei einer Newsseite über 4183674 Themen minütlich ändert, "cached"/optimiert man das, was man optimieren kann und das, indem man den Query nicht jedes mal neu parsten muss sondern einfach nur CALL XX und ende.
sorry jungs, woher habt ihr all diese informationen, ich meine ihr hantiert hier mit vielleicht und möglich. wo sind den mal konkrete fakten ? meines wissens wird das ergebnis gar nicht gespeichert, welchen sinn sollte das haben. was gespeichert wird ist zum beispiel der ausführungsplan einer sql anweisung.
Ilja
-
-
-
-
Hallo,
ich wollte mir auch mal die Informationen über parametrisierte Statements
auf der Site http://linuxfinances.info/info/sqlqueries.html ansehen aber ich finde es nicht.Wo steht da etwas darüber?
MfG
-
Hallo,
ich wollte mir auch mal die Informationen über parametrisierte Statements
auf der Site http://linuxfinances.info/info/sqlqueries.html ansehen aber ich finde es nicht.Wo steht da etwas darüber?
das steht nur indirekt da:
Der Ausführungsplan ist davon abhängig, über welchen Wert die WHERE-Klausel einschränkt. Stelle Dir diesen Wert als Aufrufparameter der SP vor. Für diese gilt ganz genau das gleiche: Der Ausführungsplan ist von den vorhandenen Daten und dem *aktuellen* Wert in der WHERE-Klausel abhängig. Entweder die SP ermittelt zur Laufzeit den Plan oder sie vertraut auf den im Durchschnitt besten Plan. Im Fall a) ist es Aufwand, in Fall b) nicht so performant wie die Ad-hoc-Query.Geht es um dynamisch zusammengestellte Queries, kann - wie Ilja ausgeführt hat - eine Vorkompilierung gar nicht stattfinden, da die Query sowieso erst zur Laufzeit bekannt ist.
Freundliche Grüße
Vinzenz
-
Hallo,
Geht es um dynamisch zusammengestellte Queries, kann - wie Ilja ausgeführt hat - eine Vorkompilierung gar nicht stattfinden, da die Query sowieso erst zur Laufzeit bekannt ist.
Dynamische Queries sollten auch nicht verwendet werden, sondern Parameter.
z.B.:
INSERT INTO ARTIKEL(A_NR, A_NAME, A_PREIS)
VALUES(12, 'Oberhemd', 39.80)wird zu:
INSERT INTO ARTIKEL(A_NR, A_NAME, A_PREIS)
VALUES(@anr, @aname, @apreis)wobei die Werte für @anr, @aname und @apreis beim Aufruf der Prozedur übergeben werden.
Eine Prozedur zu verwenden um darin dynamische SQL-Statements, sprich Strings zusammen zu bauen ist Unfug (wenn das einziger Zweck ist) und erzeugt in der Tat Overhead. Ich ging davon aus, dass dies klar ist.MfG
-
Dynamische Queries sollten auch nicht verwendet werden, sondern Parameter.
aha, und wo steht das, dass man diese nicht verwenden soll, ich meine vorauf beziehst du diese aussagen ?
Ilja
-
Hallo Ilja,
hast Du schon einmal eine SP erstellt?
Hast Du eine einzelne dynamische SQL Anweisung in der SP ausführen lassen?
MfG
-
hast Du schon einmal eine SP erstellt?
ja
Hast Du eine einzelne dynamische SQL Anweisung in der SP ausführen lassen?
ja
-
Hallo Ilja,
hast Du schon einmal eine SP erstellt?
ja
Hast Du eine einzelne dynamische SQL Anweisung in der SP ausführen lassen?
ja
Jetzt überraschst du mich!
Und wie sah es mit der Performance aus? War die schlechter?MfG
-
Jetzt überraschst du mich!
Und wie sah es mit der Performance aus? War die schlechter?diskutieren wir hier die ganze zeit über:
Lohnt es sich _alle_ Queries als SP zu speichern?
Letztendlich ja theoretisch schon, denn jeder Query wird ein funken schneller ausgeführt oder?Theoretisch lohnt es sich. Ja.
oder reden wir darüber:
Und wie sah es mit der Performance aus? War die schlechter?
entscheide dich mal, welche aussage du treffen willst. mein statement ist, SQL aus einer sp heraus ist langsamer oder aber höchtens gleich schnell (differenz läßt sich nicht messen, bzw. ich zu vernachlässigen). und nichts anderes habe ich gesagt. sp haben ihre berechtigungen und ja, ich führe täglich SQL aus sp heraus aus. tue ich das wegen der performance, ganz klar nein. isonfern kann es auch keine theoretisch geben, dass es sich lohnt.
Ilja
-
Hallo Ilja,
diskutieren wir hier die ganze zeit über:
Lohnt es sich _alle_ Queries als SP zu speichern?
Letztendlich ja theoretisch schon, denn jeder Query wird ein funken schneller ausgeführt oder?
Theoretisch lohnt es sich. Ja.oder reden wir darüber:
Und wie sah es mit der Performance aus? War die schlechter?
entscheide dich mal, welche aussage du treffen willst. mein statement ist, SQL aus einer sp heraus ist langsamer oder aber höchtens gleich schnell (differenz läßt sich nicht messen, bzw. ich zu vernachlässigen). und nichts anderes habe ich gesagt. sp haben ihre berechtigungen und ja, ich führe täglich SQL aus sp heraus aus. tue ich das wegen der performance, ganz klar nein. isonfern kann es auch keine theoretisch geben, dass es sich lohnt.
Ilja
ich glaube diskutieren kann man nur wenn die Gesprächspartner auf die Argumente des anderen eingehen.
Das kann ich bei dir nicht erkennen. Während der gesamten Diskussion wechselst du das Thema sobald es Dir nicht genehm ist. Fragen die Dir nicht passen beantwortest du nicht! Das Ganze ist Zeitverschwendung!MfG
-
Fragen die Dir nicht passen beantwortest du nicht!
dann werde doch mal konkret, welche fragen sind den für dich noch offen, die nicht beantwortet wurden ?
Ilja
-
-
-
-
-
-
-
-
-
-
-
Hallo,
Ich denke 'Parsen' und 'Kompilieren' schliesst auch die Datenbanksprache SQL ein!
das kann ja in vielen bereichen schon gar nicht gehen, alleine weil man dort dynamisches sql einsetzen kann, sprich SQL, dass erst zur laufzeit gebildet wird. wie soll ich das den vorher parsen ???
Das DBMS parst und analysiert den Code der SP, darunter auch SQL-Commands. Um Daten zu übergeben werden Parameter genutzt. Das hat erstens den Vorteil, dass der SQL-String ebenfalls kompiliert werden kann und zweitens wird so SQL-Injection ausgeschlossen.
Es wäre unsinnig innerhalb der SP einen einzelnen Query-String zusammenzusetzen (der natürlich nicht vorher geparst und kompiliert werden könnte), da somit diese Vorteile der SP zunichte gemacht würden.http://www.oracle.com/technology/tech/pl_sql/pdf/doing_sql_from_plsql.pdf
ab Ende Seite 6, Anfang seite 7 wird es interessant:
"Then, at run time, appropriate calls are made to parse, bind, and execute the
regular SQL statement."Zu Oraclespezifischen Dingen kann ich nicht viel sagen. Für mich klingt PL/SQL aber nach einer internen Programmiersprache des Oracle-DBMS, die mit SQL nur insofern zu tun hat als sie SQL-Querystrings ausführen kann? Den zitierten Ausschnitt würde ich nicht auf SP's beziehen wollen?
MfG
-
Das DBMS parst und analysiert den Code der SP, darunter auch SQL-Commands.
sicherlich macht es das dbms, aber nicht mit der gleichen engine. und alle SQL statements innerhalb einer sp sollten zur laufzeit geparst werden.
Es wäre unsinnig innerhalb der SP einen einzelnen Query-String zusammenzusetzen
weißt du was dynamisches SQL ist, hast du es schon mal benutzt ?
Zu Oraclespezifischen Dingen kann ich nicht viel sagen. Für mich klingt PL/SQL aber nach einer internen Programmiersprache des Oracle-DBMS, die mit SQL nur insofern zu tun hat als sie SQL-Querystrings ausführen kann? Den zitierten Ausschnitt würde ich nicht auf SP's beziehen wollen?
auch hier wundert es mich, was du da sagst. bei jedem DBMS ist SQL <> SP. eine stored procedure ist keine erweiterung von SQL und umgekehrt, es sind streng genommen zwei verschiedene dinge, die über zwei verschiedene engines ausgeführt werden. insofern sind bei jedem dbms die sp eine interne prgrammmiersprache, nicht nur bei Oracle.
gut, genug der worte, zeige mir einen link zu einer offiziellen Doku wo steht, dass eine SQL anweisung in einer sp zur laufzeit nicht mehr geparst werden muss (ausgenommen, wenn sie im SQL Cache schon vorgehalten wird).
Ilja
-
Aber hallo,
gut, genug der worte, zeige mir einen link zu einer offiziellen Doku wo steht, dass eine SQL anweisung in einer sp zur laufzeit nicht mehr geparst werden muss (ausgenommen, wenn sie im SQL Cache schon vorgehalten wird).
jetzt reicht es aber!
"gut, genug der worte, zeige mir einen link zu einer ..."
Ich glaub ich hör nicht richtig.Wir sollten mal zum Ausgangspunkt zurückkehren. Deine Antwort auf meine Aussage:
Ich habe noch nirgends gelesen, dass eine SP der Performance schadet, lasse mich aber gerne vom Gegenteil überzeugen.
war:
tut sie, wenn du nur reines sql damit ausführst, dann hast du einen overhead
Außer diesem Oraclespezifischen PL/SQL Link (bei dem es um SQL-Strings oder so ging) habe ich noch nirgends lesen können, das in einer SP enthaltene parametrisierte SQL Statements in einer SP nicht geparst und gecached werden und eine SP somit langsamer ausgeführt wird als ein SQL-Statement. Wenn Du mir bitte diese Aussage, die Ausgangspunkt unserer Diskussion ist, mit irgendwas belegen könntest wäre ich Dir dankbar! Und bitte nicht wieder auf andere Themen ausweichen oder Sonderbeispiele für in SP's erstellte SQL-Statements als Beispiel anführen, sonst diskutieren wir noch in Jahren.
Ganz simple Frage: "Wo schaden SP's der Performance?"
MfG
-
Hallo,
dass eine SQL anweisung in einer sp zur laufzeit nicht mehr geparst werden muss (ausgenommen, wenn sie im SQL Cache schon vorgehalten wird).
das fällt mir erst jetzt auf. Du willst wohl gerade das Hintertürchen öffnen?
Natürlich ist sie im SQL Cache mit der SP. Wo sonst?
Aber sicher erklärst Du nir gleich, dass ich das so nicht explizit gesagt hab und Du das schon immer wusstest und meintest.
MfG
-
Aber sicher erklärst Du nir gleich, dass ich das so nicht explizit gesagt hab und Du das schon immer wusstest und meintest.
du wirst albern, der Cache für SQL anweisungen hat nichts damit zu tun, ob eine SQL anweisung aus einer sp heraus ausgeführt wird oder nicht. ich sage damit, dass sie im cache stehen kann, das kann man nicht als vorteil für eine sp gelten lassen, weil das für alle SQL anweisungen gilt, egal woher sie kommen.
Ilja
-
Hallo Ilja,
Aber sicher erklärst Du nir gleich, dass ich das so nicht explizit gesagt hab und Du das schon immer wusstest und meintest.
du wirst albern, der Cache für SQL anweisungen hat nichts damit zu tun, ob eine SQL anweisung aus einer sp heraus ausgeführt wird oder nicht. ich sage damit, dass sie im cache stehen kann, das kann man nicht als vorteil für eine sp gelten lassen, weil das für alle SQL anweisungen gilt, egal woher sie kommen.
Und schon wieder willst Du ablenken!
"das kann man nicht als vorteil für eine sp gelten lassen, weil das für alle SQL anweisungen gilt, egal woher sie kommen."
Dass es ein Vorteil von SP's gegenüber SQL-Statements ist habe ich nie behauptet und war auch nie Mittelpunkt unserer Diskussion.Ich breche an der Stelle ab, sonst nimmt das hier nie ein Ende.
MfG
-
Ich breche an der Stelle ab, sonst nimmt das hier nie ein Ende.
mach das, fazit: es macht keinen sinn einzelne SQL anweisungen aufgrund von performance gründen in eine sp auszulagern.
Ilja
-
-
-
-
-
-
-
-
-
-
-
-
-
Hallo Phil,
Lohnt es sich _alle_ Queries als SP zu speichern?
nein. Ganz klar: Nein!
Du bist auf dem falschen Dampfer, wenn Du SPs als Allheilmittel ansiehst. Mikrooptimierung ist der falsche Weg.
Da Du anscheinend Scheuklappen angezogen hast und unbedingt SPs verwenden willst, willst Du nichts lesen oder annehmen, was nicht in Dein Bild passt. Das ist keine gute Ausgangsbasis.
Zur Performance: Messe! Messe mit *Deinen* Daten. Messe erneut, wenn sich Deine Daten signifikant geändert haben. Denke daran, dass sich Ausführungspläne anhand vorhandener Daten ändern können.
Freundliche Grüße
Vinzenz
-
moin,
Du sagst die Performance sei deutlich besser - jeder sagt was anderes. Allgemein lese ich aber auch das die Performance deutlich besser sei.
die frage ist doch schneller als was und nicht schneller als sql. ich mag mich bei MySQL täuschen, aber die engine um Code in einer StoredProcedure auszuführen wird eine SQL anweisung der SQL engine übergeben, sprich nicht selbst ausführen. es wird also nichts andere als SQL ausgeührt PLUS die stored procedure inklusive des kontextwechsels zwischen der engine, die die stored procedure ausführt und der sql engine. demzufolge kann eine stored procedure im vergleich zu einem sql nur langsamer sein oder höchstens gleichschnell.
Ilja
- wesentlich höherer Aufwand für:
- wesentlich höherer Aufwand für: