PHP 5 & MySQL 5

"

12 Stored Procedures (S. 489-490)

Stored Procedures (kurz SPs) sind die wichtigste Neuerung in MySQL 5.0. Es handelt sich um selbst definierbare SQL-Prozeduren oder -Funktionen, die direkt vom My- SQL-Server gespeichert und ausgeführt werden. Mit SPs steht Ihnen eine eigene, auf SQL basierende Programmiersprache zur Verfügung. SPs ermöglichen es, einen Teil der Logik einer Datenbankanwendung vom Client zum Server zu verlagern.

In diesem Kapitel erfahren Sie zuerst, warum SPs überhaupt sinnvoll sind (höhere Geschwindigkeit, höhere Datensicherheit, weniger Coderedundanz etc.). Die weiteren Abschnitte beschreiben Details der SP-Implementierung in MySQL und geben eine Reihe von Anwendungsbeispielen. Zuletzt wird der SP-Administrator vorgestellt, ein kleines PHP-Beispielprogramm, das die Administration von SPs sehr vereinfacht.

Hinweise
Stored Procedures funktionieren in MySQL 5.0.18 zwar prinzipiell, sind aber noch nicht ganz ausgereift. In nahezu jeder MySQL-Version seit 5.0.0 gab es inkompatible Änderungen. Zuletzt wurde in Version 5.0.18 die automatische Datentypkonvertierung von Parametern geändert. Aufgrund dieser Änderungen kann es passieren, dass mit 5.0.n entwickelte SPs in Version 5.0.n+1 plötzlich nicht mehr funktionieren. Das ist besonders ärgerlich, weil MySQL seit Version 5.0.15 das Attribut Generally Available trägt und eigentlich keine inkompatiblen Änderungen mehr auftreten dürften. Es gibt momentan (Februar 2006) kaum Administrationswerkzeuge zur Verwaltung von SPs. phpMyAdmin 2.7 ist zur Administration von SPs gänzlich ungeeignet, und auch der MySQL Query Browser 1.1.20 stellt nur rudimentäre Funktionen zur Verfügung. Mehr Komfort bei der Entwicklung eigener SPs bietet der in Abschnitt 12.8 vorgestellte SP-Administrator, ein kleines PHP-Programm.

12.1 Wozu Stored Procedures?
Stored Procedures sind eine Sammlung von SQL-Kommandos, die direkt im My- SQL-Server gespeichert und auch dort ausgeführt werden. Je nach Anwendung können sich daraus die folgenden Vorteile ergeben:

• Höhere Geschwindigkeit: Oft ist es so, dass zur Durchführung einer Datenbankoperation eine Menge Daten zwischen dem PHP-Programm und dem Datenbank-Server hin- und hertransportiert werden müssen: Das PHP-Programm führt ein SELECT-Kommando aus, verarbeitet das Ergebnis, führt mit diesen Ergebnissen ein UPDATE-Kommando aus, ermittelt LAST_INSERT_ID etc. Wenn diese Schritte alle auf dem Server in einer SP stattfinden können, erspart das ganz offensichtlich eine Menge Kommunikation und Overhead zur Datenumwandlung. SPs haben zudem den Vorteil, dass der Datenbank-Server den Code vorverarbeiten kann (so ähnlich, wie ein Compiler aus dem Quelltext eine Binärdatei erzeugt). Wie weit unter MySQL bereits derartige Optimierungsfunktionen zur Verfügung stehen und ob sie eine spürbare Geschwindigkeitssteigerung mit sich bringen, ist allerdings nicht dokumentiert. Beachten Sie, dass der Einsatz von SPs keine Garantie für eine höhere Geschwindigkeit ist! Einen Geschwindigkeitsvorteil werden Sie nur erzielen, wenn der Code der SP effizient ist.
  
  Da SQL aber eine viel primitivere Programmiersprache ist als PHP, ist in SPs nicht immer ein optimaler Code möglich. Der Einsatz von SPs führt dazu, dass der MySQL-Server stärker belastet ist, der Webserver mit PHP hingegen weniger. Ob das in Summe gut oder schlecht ist, hängt von der Gesamtkonfiguration ab. Wenn der MySQL- und der Weserver auf unterschiedlichen Rechnern laufen und der MySQL-Server der Flaschenhals ist, kann die intensive Verwendung von SPs diese Situation verschlimmern, während gleichzeitig der Weserver weniger als bisher ausgelastet ist.
• Vermeidung von Coderedundanzen, bessere Wartbarkeit: Oft ist es so, dass mehrere Anwendungen auf dieselbe Datenbank zugreifen. Dann gibt es meist in jeder Anwendung gleiche oder ähnliche Codepassagen zur Überprüfung der Eingabewerte, zum Einfügen neuer Datensätze, zur Aktualisierung anderer Tabellen etc. Wenn derartiger Code in eine SP ausgelagert werden kann, vermeidet das nicht nur Coderedundanz, sondern macht gleichzeitig alle betroffenen Anwendungen besser wartbar. Bei Änderungen am Datenbankschema muss oft nur eine SP geändert werden, nicht aber der Code in allen möglichen Einzelanwendungen.
• Erhöhung der Datensicherheit: In manchen besonders sicherheitskritischen Branchen (z.B. bei Banken) ist es unerwünscht, dass Benutzerprogramme direkt auf Tabellen zugreifen dürfen. Stattdessen müssen Client-Programme für alle Datenbankoperationen SPs einsetzen. Es gibt also SPs, um Daten abzurufen (SELECT), um neue Daten einzufügen, vorhandene Daten zu ändern etc. Auf den ersten Blick erscheint das ziemlich umständlich zu sein – und tatsächlich ist die Erzeugung und Wartung der vielen SPs natürlich ein erheblicher Aufwand. Der Vorteil für den Datenbankadministrator besteht aber darin, dass jeder Datenzugriff kontrolliert und bei Bedarf auch protokolliert werden kann. Es lassen sich so beliebig strikte Sicherheitsregeln implementieren.

"