nicht angemeldet Marc Reichelt
Marc Reichelt
Marc Reichelt
Marc Reichelt
Marc Reichelt
dedlfix
Hallo an alle,
meine Frage ist ganz einfach: Wann lohnt es sich bei MySQL, eigene Funktionen in MySQL anzulegen und dort auszuführen?
Ich habe die Möglichkeit der Wahl, da ich die Queries auch mit PHP erzeugen und dann ausführen könnte.
Nur stelle ich mir die Frage, was denn wohl - in welchem Fall - besser ist.
Was mache ich, wenn ich beispielsweise eine Methode mit dem Namen "create_user(id, nickname, email, ...)" habe, die einen Benutzer anlegt und TRUE oder FALSE am Ende zurückgibt - lohnt es sich hierfür, eine MySQL-Funktion anzulegen, die mir anschließend TRUE im Erfolgsfall oder FALSE im Fehlerfall zurückliefert?
Und wie sieht das aus, wenn ich eine Funktion bzw. Prozedur "get_user(id)" habe, die mir nicht nur einen Datentyp, sondern eigentlich eine ganze Tabelle zurückliefern sollte? Besseres Beispiel: Eine Funktion bzw. Prozedur "get_categories()", die mir gleich mehrere Zeilen zurückliefert.
Wann macht es Sinn, das mit MySQL zu machen?
Grüße
Marc Reichelt || http://www.marcreichelt.de/
hi Marc,
meine Frage ist ganz einfach: Wann lohnt es sich bei MySQL, eigene Funktionen in MySQL anzulegen und dort auszuführen?
das, und auch deine Beispiele, kann man pauschal kaum beantworten, ohne die Umgebung zu kennen. Auch kann sich die Antwort mit der Änderung der Umgebung ändern. Ist der MySQL-Server dediziert? Wie sind die Server (Web/MySQL) ausgelastet? Wie ist die Netzwerkverbindung zwischen Web- und MySQL-Server?
Bei bestimmten Aufgaben gilt es abzuwägen, wo der Flaschenhals sitzt: müssen für eine aufwendige Berechnung beispielsweise viele Daten vom MySQL- zm Webserver übertragen werden, könnte das Netzwerk der Flaschenhals sein. In diesem Fall könnte es sinnvoll sein, die Berechnung vom MySQL-Server durchführen zu lassen und nur die Ergebnisse zum Webserver zu übertragen. Ist dagegen die Berechnung dermaßen aufwendig, dass der MySQL-Server damit nicht fertig wird, kann es andersrum aussehen.
Ich möchte aber behaupten, dass es in den meisten Fällen, in denen sich Web- und MySQL-Server auf derselben Maschine befinden, relativ egal ist, wer von beiden die Berechnung durchführt (obwohl natürlich auch dort gilt, wenn einer von beiden bereits an seinem Limit angekommen ist, er nicht noch mit weiteren Aufgaben belastet werden sollte).
Gruß,
Andreas.
Hallo Andreas,
das, und auch deine Beispiele, kann man pauschal kaum beantworten, ohne die Umgebung zu kennen. Auch kann sich die Antwort mit der Änderung der Umgebung ändern. Ist der MySQL-Server dediziert? Wie sind die Server (Web/MySQL) ausgelastet? Wie ist die Netzwerkverbindung zwischen Web- und MySQL-Server?
In diesem Fall laufen MySQL und Apache direkt auf einem Server.
Ich möchte aber behaupten, dass es in den meisten Fällen, in denen sich Web- und MySQL-Server auf derselben Maschine befinden, relativ egal ist, wer von beiden die Berechnung durchführt (obwohl natürlich auch dort gilt, wenn einer von beiden bereits an seinem Limit angekommen ist, er nicht noch mit weiteren Aufgaben belastet werden sollte).
Natürlich. Ich habe meine Frage vermutlich auch falsch formuliert - bei Berücksichtigung der Performance kommen noch ganz andere Dinge hinzu.
Aber primär interessiert mich momentan, ob so etwas wie ich möchte (Tabelle als Resultat einer MySQL-Funktion bzw. -Prozedur) überhaupt machbar ist - und wenn ja, ob man dann dies dann besser auf MySQL oder auf PHP laufen lassen möchte.
Speziell gibt es also beispielsweise eine Funktion "get_user(parameterA, parameterB, ..., parameterN)" in PHP (die es so oder so gibt), für die nun aber der ganze SQL-Code im PHP-Code drinnen steht. Das kann schon sehr verwirrend aussehen. Daher nun die Frage, ob man nicht einfach eine gleichnamige Funktion get_user(parameterA, parameterB, ..., parameterN) in MySQL erstellt, die dann den ganzen MySQL-Code enthält, und die dann von der entsprechenden PHP-Methode aufgerufen wird.
Sodass ich nicht mehr einen Query in der Form "SELECT id, name, ... FROM table WHERE ..." schreiben muss, sondern stattdessen einfach eine Funktion aufrufe. Ist das möglich?
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Hallo nochmals,
Sodass ich nicht mehr einen Query in der Form "SELECT id, name, ... FROM table WHERE ..." schreiben muss, sondern stattdessen einfach eine Funktion aufrufe. Ist das möglich?
Ja, es geht - sehr gut sogar.
Allerdings steht hier nichts davon, dass man Prozeduren so einsetzen kann. Barf.
Ein einfaches Beispiel wäre folgendes:
CREATE PROCEDURE getAllCategories() SELECT * FROM categories;
Dann kann man über
CALL getAllCategories();
die Prozedur aufrufen - und bekommt eine Tabelle zurück, so wie ich mir das wünsche. :-)
Ich vermute, dass es sinnvoll ist, die SQL-Logik in Prozeduren auszulagern - damit diese riesigen SELECTs (nicht wie im Beispiel) den PHP-Code nicht belasten. Liege ich da richtig? Welche Gründe würden gegen weiten Einsatz der MySQL-Prozeduren sprechen?
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Moin!
Welche Gründe würden gegen weiten Einsatz der MySQL-Prozeduren sprechen?
Die Nichtverfügbarkeit von MySQLI in PHP.
- Sven Rautenberg
Hallo Sven,
Welche Gründe würden gegen weiten Einsatz der MySQL-Prozeduren sprechen?
Die Nichtverfügbarkeit von MySQLI in PHP.
Wird MySQLI zwingend zum Aufrufen von Prozeduren benötigt? Zum Erstellen bzw. Löschen der Prozeduren habe ich Zugriff auf das Programm "mysql".
Ich kann MYSQLI (sowohl lokal als auch auf dem Server) installieren - aber bei php.net steht, dass die Erweiterung MySQLI experimentell ist. Wie sicher kann ich mir sein, dass MySQLI auch in PHP 6 zur Verfügung stehen wird?
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Moin!
Welche Gründe würden gegen weiten Einsatz der MySQL-Prozeduren sprechen?
Die Nichtverfügbarkeit von MySQLI in PHP.
Wird MySQLI zwingend zum Aufrufen von Prozeduren benötigt?
Zwingend vielleicht nicht, aber aus Symmetriegründen: Ich würde davon erstmal ausgehen. Eine Prozedur könnte ja mehr zurückgeben, als nur eine einzige Tabelle. Genauso wie man Prozeduren ohne MySQLI nicht in der DB anlegen kann.
Zum Erstellen bzw. Löschen der Prozeduren habe ich Zugriff auf das Programm "mysql".
Das würde ich dann als Nachteil bezeichnen, denn so einen administrativen Zugriff kannst du nicht unbedingt voraussetzen. Das hätte also nachteilige Auswirkungen auf die Portierbarkeit deiner Applikation.
Ich kann MYSQLI (sowohl lokal als auch auf dem Server) installieren - aber bei php.net steht, dass die Erweiterung MySQLI experimentell ist. Wie sicher kann ich mir sein, dass MySQLI auch in PHP 6 zur Verfügung stehen wird?
Du liest zuviel deutsche PHP-Doku.
De facto steht das alte mysql-Paket eher kurz vor dem Rauswurf, als dass mysqli experimentell ist.
- Sven Rautenberg
Hallo Sven,
Wird MySQLI zwingend zum Aufrufen von Prozeduren benötigt?
Zwingend vielleicht nicht, aber aus Symmetriegründen: Ich würde davon erstmal ausgehen. Eine Prozedur könnte ja mehr zurückgeben, als nur eine einzige Tabelle. Genauso wie man Prozeduren ohne MySQLI nicht in der DB anlegen kann.
Dann mache ich mich wohl an die Einarbeitung in MySQLI. :-)
Zum Erstellen bzw. Löschen der Prozeduren habe ich Zugriff auf das Programm "mysql".
Das würde ich dann als Nachteil bezeichnen, denn so einen administrativen Zugriff kannst du nicht unbedingt voraussetzen. Das hätte also nachteilige Auswirkungen auf die Portierbarkeit deiner Applikation.
Was bei mir nicht gravierend ist - da die Applikation wirklich nur für meinen Server ausgelegt ist.
Insgesamt sind die Anforderungen an den Server recht hoch:
Bislang spiele ich die SQL-Scripte manuell von der Konsole mit dem Befehl
mysql -u username -D database < data.sql
ein - das werde ich vermutlich erst ganz zuletzt auf PHP umstellen, denn so ist das derzeit sehr komfortabel (und sicherer).
Ich kann MYSQLI (sowohl lokal als auch auf dem Server) installieren - aber bei php.net steht, dass die Erweiterung MySQLI experimentell ist. Wie sicher kann ich mir sein, dass MySQLI auch in PHP 6 zur Verfügung stehen wird?
Du liest zuviel deutsche PHP-Doku.
Danke für die Info - ich lese ab jetzt nur noch die englische Doku.
Ich dachte bisher, dass PHP einer der Fälle ist, indem man die deutsche Dokumentation gut verwenden kann - auch für neuere Tools.
De facto steht das alte mysql-Paket eher kurz vor dem Rauswurf, als dass mysqli experimentell ist.
Diese Information freut mich - dann werde ich wohl mein Web-Projekt nun auf MySQLI und auf PROCEDURES umstellen (was nicht schwer ist, da ich den Datenbankzugriff bisher sowieso durch eine Klasse realisiert habe). Aber die PROCEDURES erfordern doch einige größere Umstellungen, die sich aber lohnen - da der PHP-Code dann um einiges einfacher wird.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Hi,
Du liest zuviel deutsche PHP-Doku.
Danke für die Info - ich lese ab jetzt nur noch die englische Doku.
Ich dachte bisher, dass PHP einer der Fälle ist, indem man die deutsche Dokumentation gut verwenden kann - auch für neuere Tools.
Nei-en :-)
*Gerade* die PHP-Doku ist ein Paradebeispiel dafuer, dass man Uebersetzungen weniger bis teilweise gar nicht trauen sollte.
Fehlerkorrekturen, Hinweise zu neuen zusaetzlichen Funktionsparametern, Dokumentation neuer Module, etc. - das alles wird natuerlich zuerst in der englischen Version eingepflegt, und die deutsche kommt dann "spaeter irgendwann mal" dran. Man kann halt nur nie wissen, ob der Teil, den man gerade liest, schon dran war oder noch nicht :-)
Klar mag die deutsche Version etwas angenehmer zu lesen sein fuer einen Deutschsprachler - aber die englische Version zu lesen, erweitert auch die eigenen Kenntnisse der englischen Sprache mit der Zeit.
Ausserdem wird bei der Uebersetzung teilweise auch sinnentstellend geschludert, Teile/Saetze fallen einfach weg, etc.
MfG ChrisB
Hallo ChrisB,
Klar mag die deutsche Version etwas angenehmer zu lesen sein fuer einen Deutschsprachler - aber die englische Version zu lesen, erweitert auch die eigenen Kenntnisse der englischen Sprache mit der Zeit.
Ausserdem wird bei der Uebersetzung teilweise auch sinnentstellend geschludert, Teile/Saetze fallen einfach weg, etc.
Das Problem ist - PHP erkennt die Standardsprache "Deutsch" von meinem Browser. Und wenn ich das Cookie zur englischsprachigen Version einmal gelöscht habe bekomme ich die Seite eben wieder auf deutsch, und nicht auf englisch.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Hi,
Das Problem ist - PHP erkennt die Standardsprache "Deutsch" von meinem Browser. Und wenn ich das Cookie zur englischsprachigen Version einmal gelöscht habe bekomme ich die Seite eben wieder auf deutsch, und nicht auf englisch.
Das kommt wohl darauf an, wie man "einsteigt".
Wenn ich einmal unterhalb von http://www.php.net/manual/en/ bin, dann "bleibt" mein Browser auch da.
Wenn man ueber irgendwelche obskuren Suchfunktionen oder Google einsteigt - dann mag das vielleicht anders aussehen.
Aber wenn ich bspw. zu einer bestimmten Funktion was wissen will, dann habe ich unter Nutzung der Autovervollstaendigung in meiner Adresszeile die gewuenschte Seite schneller, wenn ich unter /manual/en/features.xyz.php bei xyz den Funktionsnamen eben selber eintippe (und _ durch - ersetze), als wenn ich erst noch irgendeine Suchfunktion oder -maschine bemuehe ...
MfG ChrisB
echo $begrüßung;
Wird MySQLI zwingend zum Aufrufen von Prozeduren benötigt?
Eine Prozedur kann mehrere Ergebnismengen liefern. Diese müssen, soweit ich weiß, auch erst alle abgefragt werden, bevor ein neues Statement gesendet werden kann. Mehrere Ergebnismengen können jedoch nicht mit der herkömmlichen mysql-Erweiterng abgefragt werden.
Ich kann MYSQLI (sowohl lokal als auch auf dem Server) installieren - aber bei php.net steht, dass die Erweiterung MySQLI experimentell ist.
Das steht nur noch in der deutschen Übersetzung. In der Originalfassung ist dieser Hinweis schon seit Jahren verschwunden, und in den anderen Sprachen ist er auch nicht mehr zu sehen.
Wie sicher kann ich mir sein, dass MySQLI auch in PHP 6 zur Verfügung stehen wird?
Es existieren keine Pläne, mysqli in PHP6 nicht mehr zu haben. Seitens MySQL wird wohl aber gerade noch eine API entwickelt.
echo "$verabschiedung $name";
