Schmuckstück

Schon bei kleinen Mengen strukturierter Daten regt sich oft der Wunsch nach einer Datenbank. Die Hürde, einen Server aufzusetzen, hält aber nicht selten von dem an sich sinnvollen Vorhaben ab. SQLite [1] bietet einen Kompromiss zwischen Aufwand und Nutzen. Im Gegensatz zu Datenbanken wie MySQL oder Oracle handelt es sich bei SQLite nicht um eigene Server-Software, sondern um eine Bibliothek, die den Zugriff auf die in einer Datei gelagerten Daten verwaltet. Die bei anderen Datenbanken übliche Verwaltung der Berechtigungen regelt das Programm über die Zugriffsrechte zu dieser Datei.

Wie für Bibliotheken üblich bietet auch SQLite die Möglichkeit, die Software in andere Programme einzubinden. Damit stehen in diesen die Funktionen der Datenbank automatisch bereit. Daneben existieren auch Schnittstellen zu Skriptsprachen, Darunter zu Perl, PHP und Python. Schließlich gibt noch es ein Kommandozeilen-Interface, mit dessen Hilfe Sie SQLite über Shell-Befehle steuern.

Einen ähnlichen Ansatz verfolgt das Projekt Recutils [2]. Dahinter verbirgt sich ebenfalls eine Bibliothek, die den Zugriff auf die Daten verwaltet, und die wie SQLite die Möglichkeit zum Einbinden in eigene Programmen oder zum Skripten mitbringt. Die Datenbanken liegen dabei in gewöhnlichen Textdateien. Die Flexibilität der Abfragesprache SQL (siehe Kasten "Structured Query Language") steht hier, im Gegensatz zu SQLite, nicht bereit.

SELECT spalte1, spalte2, spalte3 FROM tabelle WHERE spalte1 < 10;

SELECT * FROM tabelle1, tabelle2 WHERE tabelle1.feld1 = tabelle2.feld2;

Datenbanken bieten in der Regel unterschiedliche Feldtypen an, um die darin enthaltenen Werte korrekt zu behandeln. Unglücklicherweise erweist sich SQLite in Sachen Datentypen als sehr lax: Sie dürfen durchaus einen Text in ein als Integer definiertes Feld einfügen, SQLite stört das nicht.

Ein Datumstyp fehlt übrigens komplett. Als Alternative bietet sich entweder ein Integer-Feld an (interpretiert als Unix-Timestamp), ein Text-Feld ("YYYY-MM-DD HH:MM:SS.SSS") oder ein Real-Feld (interpretiert als Julianisches Datum). Die Tabelle "Datentypen" gibt eine Übersicht über die prinzipiell in SQLite vorhandenen Typen.

In der Praxis

SQLite ist Public-Domain-Software und kommt in vielen kommerziellen und freien Projekten zum Einsatz. Prominente Beispiele: Die Webbrowser Firefox, Chrome und Safari, der Mailclient Thunderbird, die VoIP-Software Skype sowie die Mobile-Betriebssysteme Android, Symbian und iOS.

Darüber hinaus verwenden Webanwendungen wie Serendipity ( Abbildung 1), Mediawiki (Abbildung 2) und viele weitere Webapplikationen und CMS-Systeme die Software. Für große, stark frequentierte Seiten bietet sich freilich der Einsatz eines echten Datenbank-Servers an. Bei kleineren Blogs oder Wikis lohnt sich aber – vor allem, wenn der Provider nur PHP, aber keine Datenbank bereitstellt – durchaus der Griff zu SQLite. Auch für erste Experimente am heimischen Linux-PC eignet sich die schlanke Datenbank bestens.

Abbildung 1: Serendipity bietet bei der Installation die Möglichkeit an, die Daten in einer SQLite-Datenbank zu speichern.

Abbildung 2: Auch Mediawiki setzt auf Wunsch auf SQLite als Grundlage.

Falls möglich empfiehlt es sich, dabei die SQLite-Datenbank in einem Verzeichnis anzulegen, das nicht direkt im Wurzelverzeichnis der Webpräsenz liegt – etwa in /var/tmp, wo die Daten nach einem Neustart erhalten bleiben. Noch besser wäre freilich ein eigenes Verzeichnis.

Ist beides nicht möglich, weil Sie nur auf das Web-Verzeichnis Schreibzugriff haben, bleibt noch die Möglichkeit, die Datenbank mittels der Datei .htaccess vor dem direkten Zugriff schützen. Serendipity beispielsweise macht das automatisch. Ein Beispiel dazu zeigt Listing 1. Haben die Datenbanken eine andere Extension als .db (.sqlite ist ebenfalls üblich) oder andere Dateien verwenden dieselbe Extension, gilt es natürlich, die Sperre aus dem Beispiel entsprechend anzupassen.

# .htaccess-File, um *.db-Dateien
# (SQLite)  zu schützen
<Files *.db>
    deny from all
</Files>

Auf der Kommandozeile

SQLite liegt vielen Distributionen den beiden Versionen 2.x und 3.x bei. Zwischen den zwei Entwicklungslinien hat sich allerdings das Format der Datenbankdateien geändert. Daher gilt es, darauf zu achten, dass Sie die richtige Version des Kommandozeilen-Tools (sqlite für Version 2, sqlite3 für Version 3) verwenden. Ein Konvertieren zwischen den beiden Formaten klappt aber unkompliziert (Listing 2).

$ sqlite3 version3.sqlite .dump | sqlite version2.sqlite
$ sqlite version2.sqlite .dump | sqlite3 version3.sqlite

Dieser Artikel behandelt, wenn nicht anders angegeben, die aktuellere Version 3. Das passende Kommandozeilen-Tool sqlite3 akzeptiert neben Optionen auch einen Dateinamen als Parameter sowie optional die Angabe eines SQL-Kommandos. Über die Optionen ändern Sie zum Beispiel das Ausgabeformat. Der einzig notwendige Parameter ist der Dateiname der Datenbank. Steht danach noch ein SQL-Befehl, führt die Software diesen auf die Datei aus.

Alternativ setzen Sie interaktiv Befehle ab. Die eingebauten Kommandos des Tools beginnen mit einem Punkt (.help listet zum Beispiel diese Befehle auf), ansonsten folgen die Befehle im Wesentlichen der bekannten SQL-Syntax mit einem Semikolon am Ende. Die Software führt diese sofort aus.

Listing 3 zeigt eine kurze Session. Dabei gibt SQLite die Datenbank aus, die in den folgenden Programmierbeispielen zum Einsatz kommt, und zwar einmal als Liste (select * from kunden;) und einmal als SQL-Dump (.dump).

$  sqlite3 test.sqlite
SQLite version 3.7.8 2011-09-19 14:49:19
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
kunden
sqlite> select * from kunden;
1|Max Mustermann
2|John Doe
3|Erika Mustermann
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE kunden(kdnr INTEGER PRIMARY KEY, name TEXT);
INSERT INTO "kunden" VALUES(1,'Max Mustermann');
INSERT INTO "kunden" VALUES(2,'John Doe');
INSERT INTO "kunden" VALUES(3,'Erika Mustermann');
COMMIT;
sqlite> .quit