Spätestens seit den 90er Jahren gehört objektorientiertes Programmieren zum flotten Alltag. Geht es um dauerhafte Speicherung, steigen Entwickler aber immer noch auf ein rostiges Dreirad um. Damit ist Schluss: Die Objektdatenbank Db4o konserviert mit wenigen Zeilen auch komplexe Objektstrukturen.

Query by Example (QBE)

Bei der einfachsten Methode erstellt der Programmierer ein Beispielobjekt und weist Db4o an, alle Objekte aus der Datenbank zu fischen, die so aussehen wie diese Vorlage. Um beispielsweise aus dem Adressenbestand alle Kunden aus »Hinkburg« zu erhalten, erstellt er zunächst ein passendes Objekt:

Kunde vorlage = new Kunde(null, "Hinkburg", 0);

Der erste und der letzte Parameter (Name und Kundennummer) stehen auf ihren Standardwerten - in Java sind Integer-Werte standardmäßig »0«, Strings hingegen »null«. Damit weiß Db4o, dass es diese Attribute bei der Suche ignorieren soll und nur der Ortsname »Hinkburg« von Interesse ist. Dieses präparierte Beispielobjekt wandert nun in Db4o:

ObjectSet ergebnisse = db.get(vorlage);

Diese Suchanfrage liefert alle in der Datenbank gespeicherten Objekte, die vom Typ »Kunde« sind und deren Attribut »adresse« den Wert »Hinkburg« enthält. Eine entsprechende SQL-Abfrage wäre »SELECT * FROM Kunde WHERE adresse = \'Hinkburg\'«. Die Ergebnisse landen in einer Liste, die sich anschließend per While-Schleife durchlaufen lässt:

while(ergebnisse.hasNext()) {
    ((Kunde)(ergebnisse.next())).print();
}

Diese als Query by Example bezeichnete Abfragemethode ist kurz und unkompliziert, leider aber auch extrem unflexibel. So sind beispielsweise keine komplexen Verknüpfungen mit logischen Operatoren möglich, ein "Suche alle Kunden, die in Hinkburg UND Neustadt wohnen" lässt sich also nicht ausdrücken. Darüber hinaus ist eine Suche nach Standardwerten unmöglich: "Alle Personen mit der Kundennummer 0" bleibt in den Untiefen der Datenbank ebenso verschollen wie "Menschen ohne Adresse".

Native Queries

Warum formuliert man eine Datenbankabfrage nicht einfach direkt in der sowieso schon verwendeten Programmiersprache? Das fragten sich auch die Db4o-Entwickler und bauten kurzerhand die so genannten Native Queries ein. Die dahintersteckende Idee ist auch als Safe Query Objects bekannt [3]. Um beispielsweise herauszufinden, ob eine Person in »Hinkburg« wohnt, genügt es in Java oder C#, einfach das entsprechende Attribut zu prüfen:

if(einkunde.getAdresse() == "Hinkburg")
    return true;

Damit Db4o mit einer solchen Formulierung etwas anfangen kann, muss der Programmierer sie noch in eine Methode namens »match()« verpacken, die wiederum zur Klasse »Predicate« gehört. Wie so etwas aussieht, zeigt Listing 2. Das Beispiel einer Native Query gilt für Java bis Version 1.4, Java 5 verwendet dafür Generics.

01 List kundenaushinkburg = db.query(new Predicate() {
02     public boolean match(Kunde einkunde) {
03         if(einkunde.getAdresse() == "Hinkburg") return true;
04         else return false;
05     }
06 });

Damit ist die Suchanfrage bereits komplett. Db4o kramt nun in der Datenbank nach Objekten vom Typ »Kunde«. Immer wenn es einen entsprechenden Kandidaten entdeckt hat, ruft es die »match()«-Methode auf. Sie teilt Db4o wiederum mit, ob es sich tatsächlich um eines der gesuchten Objekte handelt. Da »match()« eine herkömmliche Funktion ist, eignet sie sich zur Kombination mit allen Java- beziehungsweise C#-Sprachelementen. Auch Und-Verknüpfungen sind damit kein Problem mehr, wie Listing 3 beweist. Diese Abfrage liefert alle Kunden aus Neustadt, deren Kundennummer kleiner als 6000 ist.

01 List kundenaushinkburg = db.query(new Predicate() {
02     public boolean match(Kunde einkunde) {
03         return (einkunde.getAdresse() == "Neustadt" && einkunde.getKundennummer()<6000);
04     }
05 });

Ob der Code der Abfrage syntaktisch korrekt ist, prüft der Java- oder C#-Compiler bei jedem Übersetzungsvorgang automatisch mit - was mit eingebetteten SQL-Statements nicht klappt. Wenn die eingesetzte Entwicklungsumgebung (IDE) Vorlagen unterstützt, lässt sich das Grundgerüst solcher Abfragen per Knopfdruck in den Quellcode einfügen.

Was für den Programmierer so leicht aussieht, bedeutet allerdings für Db4o unter der Haube Schwerstarbeit. Theoretisch müsste die Datenbank jedes gefundene Objekt zunächst instanziieren und anschließend durch die »match()«-Funktion pressen. Dies kostet jedoch Zeit und Hauptspeicher. Aus diesem Grund analysiert Db4o den Inhalt der »match()«-Funktion und versucht den darin enthaltenen Code in eine so genannte SODA-Anfrage zu übersetzen.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Spätestens seit den 90er Jahren gehört objektorientiertes Programmieren zum flotten Alltag. Geht es um dauerhafte Speicherung, steigen Entwickler aber immer noch auf ein rostiges Dreirad um. Damit ist Schluss: Die Objektdatenbank Db4o konserviert mit wenigen Zeilen auch komplexe Objektstrukturen.