Eingebettete SQL-Datenbanken in Java

Sowohl HSQLDB als auch Derby bringen eingebettete JDBC-Treiber mit, welche den Zugriff auf die Datenbank durch den Anwendungscode ermöglichen, ohne dabei zu sehr darauf achten zu müssen, dass es sich um eine eingebettete Datenbank handelt. Der Unterschied zum Zugriff auf eine entfernte SQL-Datenbank besteht darin, dass die JDBC-URL, die man für den Zugriff auf eine entfernte Datenbank verwenden würde, hier zusätzlich die Aufgabe übernimmt, die Datenbank zu konfigurieren. Es folgt die Initialisierung für eine HSQLDB-Datenbank:

Die URL gibt den Treiber mit „jdbc:hsqldb:“ an, gefolgt vom optionalen Pfad und dem Namen der Datenbank. Sobald die Verbindung hergestellt ist, überprüft HSQLDB, ob dort schon eine Datenbank vorhanden ist. Falls nicht, erstellt es eine. Nach der Ausführung findet man eine Gruppe von Dateien mit unterschiedlichen Endungen im Verzeichnis, die alle mit „pithydb“ beginnen.

Derby verwendet dasselbe Schema, aber mit zusätzlichen Attributen:

Bei Derby kann man mithilfe der URL eine große Anzahl von Eigenschaften übergeben. Hier sorgt „;create=true“ für das Erstellen der Datenbankdateien. Man erhält bei Derby ein Verzeichnis namens „pithydb“, welches alle Datenbankdateien enthält.

Sobald die Verbindung hergestellt ist, kann man die JDBC-API benutzen, um mit der Datenbank zu arbeiten. Wenn man die Datenbank gerade erst erstellt hat, enthält sie natürlich noch keine Tabellen. Will man sein Schema vorher erstellen, so ist es am einfachsten, wenn man die Metadaten der Datenbank abfragt, um zu sehen, welche Tabellen bereits vorhanden sind:

Dies ist eine einfache Abfrage, welche einen Ergebnissatz mit Informationen über die Tabellen der Datenbank zurückgibt. Die dritte Spalte des Ergebnissatzes ist der Name der Tabelle. Im Pithy-Code wird nur das Vorhandensein einer Tabelle überprüft und eine erstellt, falls sie noch nicht existiert. Für komplexere Anwendungen kann man natürlich auf ausgefeiltere Strategien zur Anlage von Tabellen zurückgreifen.

Wenn man eine eingebettete Datenbank verwendet, ist die Versuchung wahrscheinlich ziemlich groß, die eigenen SQL-Befehle für diese Datenbank hart zu kodieren. SQL-Dialekte variieren mehr oder weniger. HSQLDB bringt beispielsweise eigene Varianten von CREATE und CREATE CACHED mit, um eine Tabelle anzugeben, die im Speicher zwischengespeichert, auf der Festplatte aber persistent ist. Ähnlich ist es bei SQL Identity-Spalten. Neben Abweichungen in der Syntax zur Definition einer Identity-Spalte gibt es ebenfalls unterschiedliche Methoden, den Identity-Wert abzurufen. Bei HSQLDB führt man CALL IDENTITY() aus, bei Derby die Werte IDENTITY_VAL_LOCAL().