Programmierung in MySQL Teil 1 – Sinn und Unsinn

In dieser Artikelserie möchte ich ein Thema behandeln, welches meiner Meinung nach von vielen Webentwicklern vernachlässigt wird. Eines vorweg: Diese Serie ist nur für Entwickler interessant. Wer nicht programmieren kann, wird hier nicht viel verstehen und braucht sich auch keine Sorgen machen. Auch ohne MySQL-Programmierung kann man eine Webanwendung erfolgreich machen.

Aufbau der Serie

Die Serie wird insgesamt fünf sieben Teile umfassen und führt Schritt für Schritt zur effektiven Nutzung von Stored Procedures und Co:

1. Sinn und Unsinn
2. Einrichtung und Vorbereitung
3. Die erste Routine
4. Grundkonstrukte
5. Cursor
6. Trigger
7. Der Event Scheduler

Vorgeschichte von MySQL

MySQL war schon immer die Internet-Datenbank. Im Vergleich mit Produkten wie MS-SQL hatte MySQL einen deutlich schlankeren Funktionsumfang, war dafür aber schnell. Für einfache Webseiten war sie damit ideal geeignet. Da mit der Zeit die Webanwendungen jedoch immer komplizierter wurden, kamen mit MySQL 5 einige entscheidende Funktionen hinzu. Man kann seitdem Funktionen erstellen, die ähnlich wie in anderen Programmiersprachen Variablen, Konstrukte zur Ablaufsteuerung etc. beinhalten. Zusätzlich lassen sich bestimmte Ereignisse mit Triggern abfangen.

Warum sollte ich das tun?

Die Frage ist natürlich berechtigt. Warum sollte man sich in eine weitere Sprache einarbeiten, wo man als Webentwickler, doch sowieso schon immer mindestens zwischen PHP, JavaScript und den Auszeichnungssprachen hin und her springen muss. Hierzu muss man sagen, dass sich jedes Problem auch über PHP und die klassischen MySQL 4 Befehle lösen lässt.

Warum sollte ich das trotzdem tun?

Es gibt zwei gute Gründe, dass man sich in die MySQL-Programmierung dennoch einarbeiten sollte:

1. Performance: PHP ist eine Skriptsprache und liegt somit als Quellcode auf dem Server. Der Interpreter muss bei jedem Aufruf den Quellcode neu interpretieren. MySQL-Routinen hingegen liegen fertig kompiliert auf dem Server und werden somit deutlich schneller ausgeführt. Dieser Unterschied macht sich besonders dann bemerkbar, wenn im Script häufig zwischen PHP und MySQL gewechselt werden muss.
2. Integrität: Dies gilt vor allem für die Trigger. Beim klassischen Weg über PHP muss man immer aufpassen, dass z.B. beim Löschen eines Useraccounts auch seine Daten in anderen Tabellen gelöscht werden. Mit einem Trigger kann man so einen Fall zentral abfangen. Mehr dazu im Trigger-Teil.

Warum sollte ich das besser nicht tun?

Die MySQL-Trigger und Routinen haben einige nervige Einschränkungen. So ist es z.B. bei manchen Routinen nicht möglich, diese rekursiv aufzurufen. Bei Triggern kann man nur fremde Tabellen bearbeiten, nicht die Tabelle, in welcher der Trigger ausgelöst wurde. Es gibt dafür zwar Workarounds, aber diese sind immer etwas umständlich. Zudem sind die MySQL-Routinen natürlich eine weitere „Baustelle“. Möchte man das Verhalten einer Anwendung verstehen, muss man diese immer mit berücksichtigen.

Fazit

MySQL-Routinen und Trigger sollte man immer dann einsetzen, wenn:

• Eine Aufgabe komplett in der Datenbank erfüllt werden kann (keine Dateien auf dem Webserver bearbeiten etc.)
• Die Aufgabe umfangreich ist und die Performance eine Rolle spielt
• Die Integrität der Daten wichtig ist und es viele Stellen gibt, wo diese gefährdet ist

Merkblatt

Damit du immer schnell nachgucken kannst wie das mit der MySQL Programmierung nochmal ging, habe ich ein zweiseitiges Merkblatt erstellt. Dort stehen alle Beispiele dieser Serie nochmal drauf. Du kannst das Merkblatt ausdrucken und mit einem Blick dein Gedächtnis auffrischen.

Jetzt herunterladen

Außerdem kannst du meine regelmäßigen Entwickler Tipps bestellen. Etwa ein Mal pro Monat verschicke ich Tipps zur Arbeit als Entwickler, sowohl zur technischen Seite als auch zur Zusammenarbeit mit Kunden.