Datenbanken effizient einsetzen

Webdatenbanken und damit untrennbar verbunden MySQL haben sich nicht nur durchgesetzt, sie haben eine ganz eigene Art von Zauber entwickelt. Der Begriff "Datenbank" hat sich den Charme einer modernen, state-of-the-art Lösung für viele Probleme erarbeitet. Aber wie viel ist dran an diesem Mythos?

Es ist interessant zu sehen, wie sich die Geschichte wiederholt und wie ausgerechnet in der sich ständig verändernden Informatikbranche die alten Hasen mit ihren Ratschlägen Recht behalten. Ich erinnere mich zum Beispiel an eine Vorlesung des Herrn Dr. Koch, seiner Zeit Mitarbeiter bei Intershop Research. Dieser berichtete in einer Vorlesung über software engineering an der Universität Jena über einige Sackgassen der Entwicklung und warnte vor einigen klassischen Fehlern. Unter anderem vor etwas, was als das "Goldene Hammer" Syndrom bezeichnet wird.
Dieses Syndrom bezeichnet die Ursache einer klassischen Fehlentscheidung in der Informatik. Dabei geht es darum, dass die Fähigkeiten einer Software überschätzt wird. Daraus folgt die Tendenz, beliebte Softwareprodukte undifferenziert und ohne genaue Kenntnis der Vor- und Nachteile für die Lösung von Problemen einzusetzen, für welche sie nicht geeignet sind. Umgangssprachlich: "ich habe einen goldenen Hammer und alle Probleme der Welt sind ein Nagel".

Ähnliches ist mit wachsender Popularität auch MySQL widerfahren.

Eines der klassischen Probleme bei webgestützten Datenbanken ist, dass viele Entwickler welche gewohnt sind Einzelplatzanwendungen zu entwerfen gern übersehen, dass es sich beim Internet um ein Netzwerk handelt, mit mehreren Nutzern, welche gleichzeitig an der gleichen Datenbank arbeiten können. Dies bedeutet, dass Datenbanken eine einzelne Ressource darstellen und das mehrere Dienste konkurrierend auf diese Ressource zugreifen können. Somit ist sehr viel mehr Aufwand notwendig, diese Ressource zu verwalten als auf einem Einzelplatzrechner mit nur einem Nutzer. Das führt dazu, dass gerade im Bereich PHP eine Vielzahl instabiler Skripte im Netz existieren, weil deren Entwickler dieses Problem entweder übersehen oder einfach ignoriert haben.

Beispiel:

Ein klassisches Beispiel ist eine Kundendatenbank. Nehmen wir an, sie haben ihre Kunde mit deren Adresse und einer Kundennummer abgelegt. Ebenso könnten alle Rechnungen und Kontobewegungen ihrer Firma erfasst sein. Mit dieser Datenbank könnten sie nun zum Beispiel alle Kunden auflisten lassen, welche unbezahlte Rechnungen haben. Oder sie rufen zu einer Kontenbewegung die passende Rechnung auf, oder zu einer Rechnung die Adresse des Kunden und so weiter.

Eine Datenbank ist und bleibt trotz Cache und Wrapper am Ende doch "nur" eine Datei und Dateizugriffe bleiben stets konkurrierend. Als Entwickler einer Webdatenbank müssen sie daher beim Entwurf damit rechnen, dass Zugriffe auf eine Datenbank zwangsläufig auch einmal kollidieren werden und im schlimmsten Fall zu Datenverlusten führen oder im besten Fall die Anwendung einfach nur etwas langsamer machen. Gleichzeitig müssen sie sich Strategien überlegen, wie sie damit umgehen. Dazu gehört auch und vor allem die Frage, ob der Einsatz einer Datenbank überhaupt sinnvoll ist.

Um diese Frage zu beantworten sollten sie sich bewusst machen, was Datenbanken können und was nicht: Die Stärke von Datenbanken ist die Abbildung von Beziehungen zwischen einzelnen Daten, sowie das Suchen nach bestimmten Daten unter Ausnutzung dieser Beziehungen.

Die Stärke einer Datenbank besteht in der Ausnutzung solcher Beziehungen. Eine Datenbank schafft Flexibilität der Daten. Allerdings nur dann, wenn diese Flexibilität zur Zeit des Entwurfs der Datenbank vorgesehen war. Was eine Datenbank dagegen schlecht beherrscht, ist das Speichern oder Abrufen von flachen Daten. Daten nennt man "flach" wenn sie keine, oder nur wenige Beziehungen zu anderen Daten aufweisen. Deswegen hat es (um bei unserem Beispiel der Kundendatenbank zu bleiben) keinen Sinn, den konkreten Text einer Rechnung ebenfalls in der Datenbank zu speichern. Hier sind sie besser beraten, wenn sie die Rechnung als einzelne Datei speichern und in der Datenbank lediglich die notwendigen Daten behalten, um den Inhalt für eventuelle Anfragen rekonstruieren zu können.

Beispiel:

Es bietet kaum Vorteile, den Inhalt eines Gästebuches in eine Datenbank zu schreiben, sofern durch das Gästebuch keine Suchanfragen an die Datenbank gestellt werden. Das Speichern oder Laden von Einträgen wird durch die Datenbank nicht wesentlich beschleunigt. Im Gegenteil: sobald sie nun eventuell noch andere Dinge in ihrer Datenbank speichern, wie die Konfiguration, Formulare und vielleicht auch HTML-Vorlagen, sorgen sie dafür, dass sich die Zugriffe aller dieser Komponenten aufsummieren. Dadurch wird ihre Seite im Endeffekt sogar langsamer.

Ebenso ist auf die Menge der Daten zu achten. Lohnt sich der Aufwand überhaupt? Wenn Sie nur eine absehbar geringe Anzahl gleichartiger Datensätze haben, beispielsweise eine einfache Konfigurationsdatei, ohne besondere Struktur und mit einfachen Zuordnungen von Schlüsseln und Werten. Eventuell sogar ohne die Notwendigkeit von Schreibzugriffen, dann ist eine einfache Konfigurationsdatei der leichtere Weg.

Bedenken sie auch: je komplizierter und ausgeklügelter ein System ist, umso leichter kann es ausfallen. Ein Datenbankserver ist und bleibt ein externes System, mit dem sie über eine Schnittstelle kommunizieren. Ergo: ein Plan für das Durchführen regelmässiger Backups sollte Teil eines guten Softwareentwurfs sein.

Ob eine Datenbank sinnvoll eingesetzt werden kann oder nicht, erkennen sie bereits in der Entwurfsphase relativ leicht, indem sie ein ER-Diagramm erstellen. Wenn sie feststellen, dass eine Entität bereits zur Entwurfszeit wenige oder gar keine Beziehungen zu anderen Entitäten besitzt, ist dies ein Hinweis darauf, dass es an dieser Stelle sinnvoll sein könnte die Datenbank in mehrere Teile aufzuspalten, oder aber statt einer Datenbank eine "normale" Textdatei zum Speichern der Daten zu verwenden.

Einen Entwurf anzufertigen und zu prüfen ist keineswegs einfach und benötigt viel Zeit. Allerdings zahlt es sich aus. Denn das besonders Tückische an Fehlern welche sie im Entwurf der Datenbank begehen ist, dass diese sich nicht sofort auswirken. Solange sie lokal auf ihrem Rechner testen, oder nur wenige Daten in ihrer Datenbank haben wirken sich diese Fehleinschätzungen nicht aus. Dies ändert sich schleichend mit jedem zusätzlichen Datum und jedem zusätzlichen Zugriff. Wenn allerdings erst einmal so viele Daten in der Datenbank gespeichert sind, dass die Auswirkungen durch längere Ladezeiten spürbar werden, ist es meistens schon zu spät. Denn dann kostet es mindestens das 10-fache an Aufwand, die bestehenden Daten ohne Schaden aus der alten Datenbank zu retten, eine neue Datenbank zu entwerfen und die existierenden Daten in das neue System zu übertragen.

(ac/tom) Diskussion