Auch Flatfiles können SQL

Als die PHP-Entwickler im Juni letzten Jahres die erste Beta von PHP 5 vorstellten, beunruhigte zahlreiche User die Ankündigung, dass die MySQL-Client-Library in Zukunft wegen Lizenzproblemen nicht mehr zum Lieferumfang von PHP gehören soll. Statt dessen wird SQLite mit PHP ausgeliefert werden. Auch wenn man momentan daran arbeitet, die Lizenzprobleme zu beseitigen, bleibt SQLite doch in PHP enthalten und ist dank seiner unkonventionellen Architektur eine höchst interessante Entwicklung, die man unbedingt etwas genauer unter die Lupe nehmen sollte.

Sprachschule für Flatfiles

Relationelle Datenbanken (RDBMS) wie MySQL, PostgreSQL oder Oracle sind Daemons, die als eigene Prozesse laufen. Will man nun von einer Software aus Daten mit ihnen austauschen, benötigt man dazu in der Regel die passende Client-Library. Der grosse Nachteil dieser Client-Server-Architektur ist der relativ grosse Overhead, der bei der Kommunikation zwischen Client und Server entsteht und für entsprechende Geschwindigkeitseinbussen sorgt.

Dieses Problem kennt SQLite nicht. SQLite ist, im Gegensatz zu den grossen Datenbanken, ein SQL-Aufsatz für Flatfiles: Man braucht keinen Datenbankserver zu installieren, sondern arbeitet mit SQL-Queries direkt auf einer normalen Datei.

Was diese Architekturänderung bedeutet, kann man nach einem Studium der Geschwindigkeitsmessungen auf der SQLite-Homepage erahnen: Galt bei SQL-Datenbanken in Bezug auf Geschwindigkeit MySQL bisher als das Mass aller Dinge, überrascht es, wenn SQLite bis zu zweimal schneller als MySQL und sogar bis zu 20 mal so schnell wie PostgreSQL sein soll. Auch wenn diese Werte unrealistisch erscheinen, wurden sie in diversen Newsgroup-Postings bereits bestätigt.

Hinzu kommt, dass SQLite im Gegensatz zu MySQL auch Stored Procedures, Transaktionen und Subqueries beherrscht, alles Funktionen, die MySQL erst seit einiger Zeit einbaut erhält. Angesichts dieser Funktionsauswahl und der fast kompletten Kompatibilität zu ANSI SQL 92 wird sich so mancher Entwickler am Ziel seiner Träume wähnen.

Lösung für viele Probleme

Das Flatfile-Prinzip von SQLite dürfte auch viele Probleme lösen. So musste, wer datenbankgestützte Applikationen ready-to-run auf CD benutzen wollte, bisher abgespeckte Versionen von MySQL oder PostgreSQL einsetzen, die man meist zuerst auf der Präsentationsmaschine installieren musste. Mit SQLite fällt dies grösstenteils bis komplett weg und man kann trotzdem auf ein datenbankähnliches Interface zugreifen.
Auch die unzähligen kleinen Applikationen für Shared-Webhosting-Umgebungen dürften profitieren, bei denen man oftmals auf eine Datenbank verzichten muss. So konnte man bisher keine dynamischen Applikationen einsetzen oder musste Textdateien als Datenspeicher verwenden, was einerseits langsam ist und andererseits viel weniger Möglichkeiten als eine SQL-Datenbank bietet. Ist SQLite, beispielsweise im Rahmen von PHP 5, standardmässig verfügbar, dürften diese Applikationen ein grosses Technologie-Upgrade erfahren.
Eine weitere Funktion, die einige Software-Entwickler für sinnvoll halten und fast schon sehnsüchtig erwartet haben dürften, ist die Möglichkeit, Session-Daten komplett in einer Datei speichern zu können, ohne erst ein RDBMS bemühen zu müssen. Dies wird momentan auch auf den PHP-Entwicklerlisten diskutiert. So plant man, den Standard-Session-Handler von Files auf SQLite umzustellen. In einigen Performance-Tests wurde dabei aber ein Problem von SQLite aufgedeckt: Bei vielen Concurrent Users und grossen Datenmengen bekommt SQLite Probleme, die Anfragen effizient und schnell zu verarbeiten, so das die Performance zum Teil erheblich einbricht.

SQLite statt MySQL?

Vor allem für Programmierer und Administratoren dürfte SQLite eine erstzunehmende Alternative zu MySQL darstellen, da sich die Kompatibilität und die Last auf Webservern verringern lässt, sofern sich bei den Webseiten die Concurrent User in Grenzen halten.

Entscheidend ist dabei vor allem die Kompatibilität zu MySQL. Hier sind auf Ebene von SQL eigentlich alle Fähigkeiten vorhanden, die man im täglichen Betrieb benötigt. Einzig Befehle, die im Webseiten-Alltag weniger benutzt werden, sind nicht implementiert. Beispiele dafür sind die Funktionen ALTER TABLE, TRUNCATE TABLE, RIGHT JOIN sowie FULL OUTER JOIN, wobei sich für diese meist durch eine leichte Umformulierung der SQL-Queries eine identisch arbeitende Lösung finden lässt.

Administratoren dürfte das Fehlen von GRANT schmerzen. Da SQLite nur auf Dateiebene operiert, sind die einzigen Sicherungsmassnahmen gegen unbefugten Zugriff die Schutzmechanismen des Filesystems, unter unixoiden Systemen also chown/chgrp oder chmod. Ein fein granuliertes Rechtesystem findet man nur bei den grossen RDBMS, weil die Server über eine eigene Rechteverwaltung verfügen, die vom Filesystem unabhängig funktioniert.

Auf der Seite der Scriptsprachen, wo man als Beispiel PHP 5 herbeiziehen kann, ist die Kompatibilität unter Umständen nicht ganz so einfach zu erreichen. Da es sich bei SQLite um ein eigenständiges Modul handelt, sind API-Funktionen natürlich anders benannt. Wer also ohne einen Abstraktionslayer wie Adodb oder PEAR::DB arbeitet, wird sämtliche Scripte durchforsten und die Befehle ändern müssen, um SQLite nativ ansprechen zu können.