Das Konzept hinter dem DDDBL

Übersicht

Einführung

Die Arbeit mit Datenbanken gehört für viele PHP-Entwickler zum Alltag. Dennoch stellen die verschiedenen Datenbanksysteme mit verschiedensten Features, Funktionsweisen und allerlei Besonderheiten eine große Herausforderung da. Datenbanken sind ein nicht zu unterschätzendes Teilgebiet, dessen Beherrschung eine Herausforderung und gleichzeitig eine Grundlage der täglichen Arbeit darstellt. Der DDDBL versucht die Arbeit so stark wie möglich zu vereinfachen, ohne irgendwelche Einschränkungen vornehmen zu müssen. Die angestrebten Vereinfachungen sind in den folgenden Abschnitten erklärt.

Datenbank-Abstraktion

Lange Zeit war es umständlich mit verschiedenen Datenbanksystemen zu arbeiten. MySQL, Oracle, PostgreSQL - alle hatten eigenständige Funktionen in PHP und deren Verwendung unterschied sich zum Teil stark - insbesondere da die PHP-Funktionen sich zum Teil stark an die jeweiligen Datenbank-Features anlehnen.
Mit Einführung von PDO in PHP 5.1 wurde diese Problematik stark entschärft - aber noch lange nicht behoben. Die Arbeit mit mehreren Datenbanken gleichzeitig, die Verwendung von Prepared-Statements und die Arbeit mit den Ergebnissen gestaltet sich zum Teil noch immer unnötig kompliziert.
DDDBL abstrahiert daher diese neue Funktionalität und gibt Ihr ein leicht zu verwendendes Interface.

Das Prinzip ist dabei ganz einfach: Jede Datenbankverbindung benötigt eine einmalige Konfiguration - Host, Datenbank, Benutzername und dessen Passwort. Diese Daten ändern sich für gewöhnlich nicht. Im DDDBL werden sie daher in einer Konfigurationsdatei hinterlegt. Um eine höhere Lesbarkeit und ein besseres memoisieren zu gewährleisten, muß jede Verbindungsdefinition mit einem Alias - also einem Namen - verknüpft sein.

Möchte der Entwickler jetzt mit einer Datenbank arbeiten, erzeugt er ein neues DDDBL Objekt und gibt den Datenbankalias an - z.B. "CMS-DEVEL" oder "Kundenshop". Möchte er mit einer weiteren Datenbank arbeiten, erzeugt er ein anderes DDDBL Objekt und nutzt einen anderen Datenbankalias. Die Arbeit mit multiplen Datenbank innerhalb einer Applikation ist somit außerordentlich einfach.

Die Verwaltung der Datenbankverbindungen - das Öffnen und Schließen der Verbindungen, die Zuordnung der Abfragen zu den jeweiligen Datenbanken und anderes wird durch DDDBL vollständig übernommen. Alles was der Entwickler machen muß, ist die Konfiguration zu hinterlegen und ein Objekt zu erzeugen.

SQL-Query-Abstraktion

Eine Datenbankabfrage wird regelmäßig innerhalb des Quellcodes vorgenommen. Das ist der Meinung des Autors nach jedoch der völlig falsche Platz. Denn der Query wird somit zum festen Bestandteil des Programmes - obwohl Programm und Datenbank funktionell und häufig auch physikalisch getrennt sind.

Das übliche Vorgehen hat daher eine Reihe von Nachteilen. Als Teil des Programmes schlägt sich jede Strukturänderung der Datenbank in den Applikationscode nieder - jede Änderung einer Abfrage ist gleichzeitig eine Programmänderung. Jede Programmänderung zieht eine Reihe von Testzyklen hinter sich her - und testen ist aufwändig.
Als Bestandteil des Programmcodes lassen sich selbst einfachste Datenbankabfragen nicht automatisiert erzeugen. Sie sind - sollte das Programm nicht explizit darauf ausgelegt sein - auch nicht mehr wiederverwendbar oder gar applikationsübergreifend nutzbar.

Der DDDBL ermöglicht daher eine strikte Trennung zwischen Programmcode und Datenbankabfrage. So wie bei der Datenbankverbindung wird ein Query unter einem Alias hinterlegt. Im Applikationscode wird lediglich der Name, sowie - falls notwendig - Parameter für den Abruf verwendet.

Dieses Vorgehen führt nicht nur zur gewünschten Trennung, sondern begründet noch eine Reihe weiterer Vorteile. So ist der Alias der Abfrage deutlich sprechender als ein mehrere Zeilen umfassender Query. Der Leser des Programmes - Programmierer, Reviewer oder andere Personen, wissen somit sofort, welche Daten die Applikation an dieser Stelle erwartet.
Durch die Trennung sind SQL-Queries auch leicht generierbar - kein Programmierer muß sich nach dem Schreiben eines Generators länger mit einfachsten Abfragen beschäftigen. Die Abfragen sind des Weiteren auch portierbar. Sie stehen in einer oder mehreren Dateien und können getrennt vom Programm verwaltet und transportiert werden.

Durch die Art der Verwaltung sind Abfragen logisch gliederbar und auch programmübergreifend verwendbar. Durch die sehr einfache Art der Definition können die Abfragen leicht zwischen Applikation portiert werden. Ebenso können diese gemeinsam genutzt oder durch andere Sprachen verwendet werden.

Eine weitere Besonderheit ist, dass Abfragen für einen spezifisches Datenbanksystem geschrieben werden können. So können je nach Situation jeweils von Hand optimierte Abfragen für ein Datenbanksystem verwendet werden.

Die Abstraktion der eigentlichen Abfrage ist jedoch noch längst nicht alles - die meisten Datenbankabfragen liefern ein Ergebnis. Auch darum kümmert sich der DDDBL.

Ergebnismengen-Abstraktion

Fast jedes Programm, dass Anfragen an die Datenbank stellt, wertet die Ergebnisse der Abfrage aus. Das ist natürlich kein Problem - das lösenswerte Problem, das der Autor sieht, ist die Art der Ergebnisverarbeitung. In der Regel wird das Ergebnis in eine bestimmte Form gebracht und auf bestimmte Datentypen gecastet. Das ist das Problem. Denn die Struktur des Ergebnisses unterliegt einem häufig angewendeten Regelwerk - jede Umwandlung ist also ähnlich. DDDBL greift diese Ähnlichkeit auf und abstrahiert sie.

Den Vorlieben des Autors folgend, werden Ergebnisse automatisch je nach Wunsch in einzelne Werte oder in assoziative Arrays, die einen einzelnen Datensatz, mehrere Datensätze oder eine Liste von Werten entsprechend, umgewandelt.

Dazu wird ein sogenannter "Handler" dem Query zugeordnet. Dieser nimmt das Ergebnis der Datenbank entgegen und bringt es in die gewünschte Form. Die Zeitersparnis bei diesem Vorgehen ist enorm - insbesondere, wenn die Datenbank die jeweiligen Daten mit korrekten Datentyp zurückgibt. Falls dies nicht so ist - kein Problem: Optional können die Daten ganz nach belieben gecastet werden.
Statt also durch das Ergebnis einer Datenbankabfrage zu iterieren und dieses in die gewünschte Form zu bringen, wird der Abfragendefinition lediglich ein Handler übergeben. Dies sind häufig ca. 15 Zeichen - statt 2 bis n-Zeilen beim üblichen Vorgehen.

Da nicht jeder die Vorlieben des Autors teilt, können sehr leicht neue Handler hinzugefügt werden. So können nach eigenem belieben Objekte zurückgegeben werden oder Daten direkt im Speicher hinterlegt werden.

Es sind auch automatische Verarbeitungen oder Auswertungen der Daten möglich. So existieren bereits Handler, die prüfen, ob eine Ergebnismenge leer ist, eine Mindestanzahl an Datensätzen existiert oder die das Ergebnis in eine CSV-Datei exportieren.

Sollten Sie einen Handler schreiben, von dem Sie überzeugt sind, dass er auch für Andere interessant sein könnte, kontaktieren Sie den Autor. Falls er Ihre Ansicht teilt, wird Ihre Erweiterung mit zum Download angeboten werden.

Arbeitsteilung

Viele Vorteile des DDDBLs ergeben sich erst aus dem Kontext der Benutzung. Der wichtigste dieser Vorteile ist die Arbeitsteilung. Wie eingangs erwähnt, ist es fordernd einen kompetenten Umgang mit den heutigen komplexen Datenbanksystemen aufzuweisen. Zum einen ist der SQL-Standard nicht gerade klein, zum anderen verhalten sich Datenbanksysteme zum Teil sehr unterschiedlich.
Soll mit der Abfrage SELECT COUNT(*) FROM tabelle die Anzahl aller Zeilen in der Tabelle ermittelt werden, führt dies häufig zu unerwarteten Geschwindigkeitsproblemen. In PostgreSQL wird tatsächlich jede Zeile gezählt. In MySQL wird dieser Wert aus den Metadaten einer Tabelle gelesen. Ist MySQL nun besser als PostgreSQL - schließlich sind die Geschwindigkeitsunterschiede bei dieser einfachen Abfrage enorm? Sicher nicht! Diesen Geschwindigkeitsvorteil erkauft sich MySQL mit dem Verzicht auf ein gutes MVCC - je nach Anforderung ein extremer Nachteil. Und letztlich weist gerade PostgreSQL gegenüber MySQL bei hoher Belastung eine deutlich bessere Geschwindigkeit auf.

Und nun stellen Sie sich den vollständigen SQL-Standard vor, der von den durch DDDBL unterstützten Datenbanksystemen auf ihre ganz eigene Art und Weise implementiert wird und um eine Reihe von Features erweitert wird. So bietet Oracle zum Beispiel Window-Funktionen und in PostgreSQL kann man funktionale Indizes verwenden. Die Vielzahl der Kombinationen und die Komplexität eines einzelnen Datenbanksystemes rechtfertigen häufig die Einstellung von Fachpersonal für ein Datenbanksystem. Nur können diese in den seltensten Fällen auch PHP, Python, Lisp und andere Programmiersprachen in einem Maße, der von Fachpersonal für diese Sprachen erwartet wird.

DDDBL greift dieses Problem auf. Durch die strikte Trennung von Programm und Datenbankabfragen kann gezielt Fachpersonal für die Erstellung und Wartung der Datenbankabfragen eingesetzt werden. Der Schulungsbedarf für das Fachpersonal, das den DDDBL verwenden soll, ist außerordentlich gering. Es muß die maximal dreizeilige Syntax einer Abfragen-Definition beherrschen und im schlimmsten Falle verstehen, welcher Handler gewählt werden sollte. Mehr nicht.

DDDBL ist kein ORM

Um einem häufigen Mißverständnis vorzubeugen: DDDBL ist kein ORM. Beide Konzepte sind grundsätzlich verschieden. ORM ist eine Technik, mit der eine objektorientiert programmierte Applikation Ihre Objekte in einer relationalen Datenbank persistieren kann.
Daraus ergeben sich bereits grundlegende Einschränkungen: Es wird eine objektorientierte Sprache und Applikation, sowie eine relationale Datenbank benötigt.
DDDBL hingegen abstrahiert die Arbeit mit der Datenbank. Es ist belanglos, ob es sich dabei um eine relationale, hierachische oder objektorientierte Datenbank handelt. Es ist ebenso ohne Bedeutung, ob die DDDBL-verwendente Applikation objektorientiert entwickelt wurde oder nicht.

Typische ORM-Frameworks haben der Meinung des Autors nach eine Reihe von Nachteilen. Sie erzeugen Quellcode, der gewartet und getestet werden muß. Mehr Quellcode bedeutet mehr Testaufwand, mehr Ressourcenbedarf (Speicher, CPU-Zyklen), mehr Wartungsbedarf und größere Auslastung des Namespaces. Dadurch steigt die Komplexität der Applikation, welches schlanke und einfache Interfaces für zum Beispiel automatisches cachen und testen stark erschwert.

DDDBL hingegen ist sehr schlank (weniger als 500 LoC) und gleichzeitig flexibel. Es kann projektübergreifend verwendet werden und ermöglicht eine einfache Wiederverwendung von Datenbankabfragen. Der Ressourcenbedarf ist sehr gering und der Namespace wird kaum in Anspruch genommen. Durch die strikte Trennung von Datenbank und Applikation werden wechselseitige Beziehungen und damit beidseitige Testzyklen, sowie aufwändige Wartung, bei einer einseitigen Änderung vermieden.

Schlußwort

Ich hoffe Ihnen einen kurzen, aber tiefen, Einblick in das Konzept hinter dem DDDBL gegeben zu haben und würde mich freuen, wenn Sie dem Projekt DDDBL eine Chance gewähren würden.
Sollten Sie Fragen, Wünsche oder andere Kritiken haben, würde ich mich über eine Kontaktaufnahme freuen.