Einheit im Datenbank-Dschungel

Während sich Entwickler bei den meisten Scriptsprachen über konsistente Datenbank-Interfaces freuen können, mit deren Hilfe man bei einem Wechsel der Datenbank schlimmstenfalls die SQL-Abfragen anpassen muss, sieht es diesbezüglich in der PHP-Welt etwas trister aus: Jede Datenbank-Extension verfügt über eigene Funktionen, die zum Teil erheblich in ihrem Funktionsumfang differieren und bezüglich Aktualität von «angestaubt» (ext/mysql) bis hin zu «taufrisch» (ext/mysqli und ext/sqlite) rangieren. Hat man nun auf eine bestimmte Datenbank wie MySQL gesetzt und möchte beispielsweise auf PostgreSQL umsteigen, müssen nicht nur einige SQL-Abfragen überarbeitet, sondern auch sämtliche mysql_*()-Funktionen durch ihre pg_*()-Entsprechungen ersetzt werden.

Alternative zur Alternative

Wollte man dies vermeiden, existierten bislang zwei Ansätze. Eine Möglichkeit bestand darin, einen Wrapper zu schreiben. Ein Wrapper sorgt für ein einheitliches Interface gegenüber den nativen Extensions und kann sich noch um die Input-Filterung und das Error-Handling kümmern. Die andere Möglichkeit war der Einsatz eines Abstraktions-Layers, der über die Funktionalität des Wrappers hinausgeht, indem er versucht, Inkompatibilitäten zwischen mehreren Datenbanksystemen auszugleichen. Mit PDO, das zum Funktionsumfang von PHP 5.1 gehören soll, steht in Zukunft eine weitere Möglichkeit zur Verfügung.

PDO, das für PHP Data Objects Interface steht, ist eine C-Extension, die von Wez Furlong, Marcus Börger, Ilia Alshanetsky und Georg Schlossnagle geschrieben wurde. Sie stellt eine einheitliche API für eine Reihe von spezifischen Datenbanktreibern dar, welche die Brücke zwischen Scriptsprache und Datenbankserver bilden. Die Ansteuerung der jeweiligen Datenbank erfolgt über einen Data Source Name (DSN), der dem PDO-Konstruktor übergeben wird:

$db = new PDO('mysql:host= 192.168.32.201;dbname=test');

Möchte man statt MySQL einen MS-SQL-Server verwenden, braucht man nur den DSN zu ändern:


$db = new PDO('mssql:host= 192.168.32.190;dbname=test');

Einfache Anwendung

Das Query-Interface ist angenehm schlank geraten. Dies lässt sich einerseits damit erklären, dass PDO auf die Pufferung von Daten verzichtet, womit einige Funktionen fehlen, die auf gepufferte Daten angewiesen sind, und andererseits spezielle Funktionen fehlen, um beispielsweise mehr über den Zustand des Servers in Erfahrung zu bringen. Beachtenswert ist vor allem für Anwender von MySQL, dass man nach den Entwicklern von PDO vorzugsweise auf Prepared Statements setzen sollte. Diese vermindern unter anderem die Gefahr von SQL Injections und können bei einer starken Nutzung gewisser Abfragen für eine bessere Ausführungsgeschwindigkeit sorgen, da eine Abfrage nur einmal vom Server analysiert werden muss.

$stmt = $db->prepare("INSERT INTO 'test' ('vorname', 'nachname') VALUES (:vorname, :nachname)");

$stmt->bindParam(':vorname', $vorname);

$stmt->bindParam(':nachname', $nachname);

$stmt->execute();

Wie man bereits sehen konnte, verhält sich PDO wie mysqli oder die im Rahmen von PHP 5 neu hinzugekommenen XML-Extensions als Objekt. Dies ist besonders bei der Fehlerbehandlung praktisch, da man PDO dazu bewegen kann, Exceptions zu werfen.

$db->setAttribute(PDO_ATTR_

ERRMODE, PDO_ERRMODE_

EXCEPTION);

Exceptions sparen die vergleichsweise aufwendige Prüfung der Resultate mit $stmt->errorCode() und $stmt->errorInfo(), da man die kompletten Datenbankoperationen in try…catch-Blöcke einfassen kann.
Summa summarum kann PDO dem geneigten Entwickler die Arbeit einfacher machen und die Entwicklung eines Datenbank-Wrappers ersparen. Allerdings muss man sich bewusst sein, dass PDO trotz der Fähigkeit, mit einem einfachen Wechsel der DSN unterschiedliche Datenbanken ansprechen zu können, keinen vollwertigen Abstraktions-Layer wie AdoDB oder PEAR::DB darstellt. Denn diese versuchen, die unterschiedliche Funktionsweise der verschiedenen Datenbanksysteme zu vereinheitlichen, und emulieren teilweise fehlende Funktionen – etwas, wozu PDO weder in der Lage noch gedacht ist.