NoSQL: Objektorientierte Datenbanken (db4o, ObjectDB)

Objektorientierte Datenbanken oder Objektdatenbanken sind eigentlich für viele heutige Applikation prädestiniert, haben sich allerdings noch nicht durchgesetzt. Stattdessen setzen wir unterschiedliche Ansätze ein, welche relationale Datenbanken für die Applikation in ein objektorientiertes Format umwandeln sollen (ein Beispiel wäre ActiveRecord).

Objektdatenbanken dienen, wie der Name schon sagt, der direkten Speicherung von Objekten, ohne sich viele Gedanken über Normalisierung oder ID-Referenzierung machen zu müssen. Vielmehr kümmert sich die Datenbank selbst um die Zuweisung von eindeutigen IDs an die gespeicherten Objekte und die Zuordnung von Objekten zueinander. Dadurch kann man die einzelnen verknüpften Objekten auch nach der Speicherung weiterhin direkt über Methoden ansprechen.

Die Abfragesprache für objektorientierte Datenbanken ähnelt start SQL und heißt auch so ähnlich: OQL. Im Gegensatz zu den relationalen Datenbanken ist das Ergebnis einer OQL-Anfrage allerdings keine Menge, sondern eine Liste von Objekten, die den geforderten Kriterien entsprechen.

Verwendung ähnlich wie viele ORMs für relationale Datenbanken

Die Verwendung von Objektdatenbanken dürfte für die meisten Entwickler nichts Neues sein. Man arbeitet oft nicht mit den eigentlich spezifizierten OQL-Queries, sondern direkt mit den Objekten, deren Attribute von einem Entity-Manager gespeichert werden. Besonders Doctrine2 zeigt hier eine starke Ähnlichkeit zu den wichtigen objektorientierten Datenbanken.

<?php
// Erzeugung des Objekts
Pilot pilot1 = new Pilot("Michael Schumacher", 100);
// Speichern des Objekts mittels Entity-Manager
db.store(pilot1);

Je nach System werden jedoch auch andere Formen der Abfrage unterstützt. Während ObjectDB OQL-Abfragen verwendet, bietet db4o Query-By-Example, Native-Queries und SODA-Queries an. Query-By-Example bedeutet, dass man ein Prototyp-Objekt mit ein paar gesetzten Eigenschaften übergibt, die man mit den Objekten in der Datenbank vergleichen will, Native-Queries sind in die jeweilige Programmiersprache eingegebettete Abfragen und SODA (Simple Object Data Access) ist eine objektorientierte Anfragemethode, bei der man den Query über verschiedene Methoden-Aufrufe konfiguriert. Native-Queries kann man mit dem Map-Reduce-Verfahren der dokumentenorientierten Datenbanken vergleichen, wenn man das Reduce-Verfahren weglässt:

<?php
// retrieveCarsByPilotNameNative
final String pilotName = "Rubens Barrichello";
List<car> results = db.query(new Predicate<car>() {
    public boolean match(Car car) {
        return car.getPilot().getName().equals(pilotName);
    }
});
listResult(results);

Fazit

Objektdatenbanken können ihre Stärken erst bei sehr komplexen Problemen ausspielen. Hat man viele einfache Abfragen sind sie im Vergleich zu den typischen relationalen Systemen langsamer. Gerade deshalb werden Objektdatenbanken vermutlich immer eher ein Produkt im kommerziellen Bereich bleiben, da es hier viel häufiger komplexe Anwendungsfälle gibt („In der Industrie sind hier nicht selten Objekttiefen von 10 bis 20 anzutreffen“, entwickler.de). Dies lag bisher natürlich auch an der fehlenden offenen Alternative, welches es mit db4o inzwischen gibt.

Letztlich hat die Verwendung von Objektdatenbanken sicherlich auch mit der verwendeten Programmiersprache zu tun, da die meisten sich logischerweise auf die typischen objektorientierten Sprachen wie Java, C++ oder C# konzentrieren. Für viele Desktop-Appliktionen mit komplexeren Verbindungen zwischen den Daten könnte sich der Einsatz einer Objektdatenbank natürlich deshalb lohnen, weil sich die Objekte direkt speichern lassen, ohne eine Zwischenschicht zu beachten. Im Web-Bereich werden sie sich vermutlich nicht durchsetzen können (wollen sie aber sicherlich gar nicht), hier geht der neue Markt eher an die dokumentenorientierten Datenbanken.