SQLite bringt zwar die Funktionalität einer relationalen SQL-Datenbank mit, kommt aber ohne aufwändig zu administrierende Server aus. Dieser Artikel vergleicht die Bibliothek mit ihren Konkurrenten und zeigt, wie man sie in eigene Programme einbaut.

SQLite und der Standard

Wichtig für den Benutzer ist, wie gut seine Datenbank den SQL-Standard[5] unterstützt. Üblicherweise erfüllen Datenbanksysteme weitgehend den Standard aus dem Jahre 1992 (auch SQL 2 genannt) mit einigen ausgewählten Features der Weiterentwicklung aus dem Jahre 1999 (SQL 3). Auch SQLite orientiert sich am SQL-2-Standard, wobei es einige Basisfunktionen relationaler Datenbanken wie das Ändern von Tabellenstrukturen mit »ALTER TABLE« oder Foreign-Key-Constraints nicht unterstützt. Andererseits bringt es einige fortgeschrittene Features wie Trigger oder Views mit, die für Desktop-Datenbanken ungewöhnlich sind.

Tabelle 1 gibt einen Überblick über Abweichungen vom SQL-2-Standard. Auffallend ist, dass SQLite keine richtigen Datentypen besitzt, ähnlich wie viele Skriptsprachen. Die wichtigsten Unterschiede zum Standard sind:

• »CREATE« verarbeitet beliebige Datentypen, die
  SQLite aber ignoriert. Intern speichert es alle Werte als
  »x00«-terminierte Strings.
• Feldinhalte fasst SQLite je nach Kontext als
  »TEXT«- oder »NUMBER«-Werte auf, zum
  Beispiel bei »SELECT Feld1 + 1 FROM ...« als
  »NUMBER« oder bei »SELECT Feld1 || 'bla'
  FROM ...« als »TEXT« (»||« ist der
  Stringverkettungsoperator in SQL).

Auch wenn SQLite-Autor Richard Hipp diese Typfreiheit in der Dokumentation als Vorteil darstellt, bringt sie einige potenzielle Probleme mit sich. So sind dann häufig Werte als Zahlen identisch, aber als String verschieden, zum Beispiel »1.0« und »1.00«. Das verletzt aber das Grundprinzip relationaler Datenbanken, dass der Anwender das interne Speicherformat nicht kennen muss.

Besonders fehlerträchtig ist das bei Datum-Strings, die je nach verwendetem Format (TT.MM.JJ, JJ.TT.MM und so weiter) verschiedene Bedeutungen haben. Im schlimmsten Fall ist nicht mal gewährleistet, dass in einem Datumsfeld überhaupt ein Datum steht, denn SQLite akzeptiert aufgrund der Typlosigkeit auch »bla« als Datum.

Konsistenz durch ACID

Über das Fehlen einer Benutzer- und Rechteverwaltung kann man bei einer Desktop-Datenbank wohl getrost hinwegsehen, weil sie typischerweise im Einbenutzerbetrieb läuft. Schwerwiegender ist die mangelnde Unterstützung für Integrity-Constraints, besonders für Fremdschlüssel (Foreign Keys).

Wenn der Entwickler weiß, dass nur seine Anwendung auf die Daten zugreift, kann er unzulässige Einträge noch selber abfangen. Wenn aber auch das Programm »sqlite« oder ein ODBC-Frontend Tabellen verändert, ist die Datenkonsistenz nicht mehr gewährleistet. Und ohne kaskadierende Updates oder Deletes, also Änderungen, die sich über mehrere Tabellen auswirken und dabei deren Konsistenz garantieren, wird die Datenpflege mühsam und fehleranfällig.

Nach so viel Genörgel folgt ein Pluspunkt von SQLite: Es unterstützt ACID-kompatible Transaktionen (siehe Kasten "Datenbankbegriffe"). Weniger wichtig bei nur einem Benutzer ist die Isolation gleichzeitig ablaufender Transaktionen, zumal SQLite sie über eine Sperre der gesamten Datenbankdatei realisiert, also im Mehrbenutzerbetrieb überhaupt keine Parallelität bietet.

Sehr nützlich ist es dagegen, Fehler mit »ROLLBACK« zu behandeln, denn damit kehrt der Anwender zu einem definierten, fehlerfreien Zustand der Datenbank zurück. Die Durability ist eine nette Zugabe, die bewirkt, dass zum Beispiel »kill -9« laufende SQLite-Transaktionen ohne Datenkorruption abwürgt.

SQLite bringt zwar die Funktionalität einer relationalen SQL-Datenbank mit, kommt aber ohne aufwändig zu administrierende Server aus. Dieser Artikel vergleicht die Bibliothek mit ihren Konkurrenten und zeigt, wie man sie in eigene Programme einbaut.