NoSQL-Datenbanken geben die feste, gemeinsame Tabellenstruktur des relationalen Modells bewusst auf und bekommen im Gegenzug ein Datenmodell, das gezielt zu einer bestimmten Art von Problem passt. Dokumentendatenbanken speichern jeden Datensatz als flexibles, in sich geschlossenes Dokument, Key-Value-Stores rufen Daten ausschließlich über einen einzigen Schlüssel ab, und Graphdatenbanken stellen die Beziehungen zwischen Datensätzen als das eigentlich Gespeicherte dar, statt diese Beziehungen als nachträglich über separate Tabellen gelegten Nachgedanken zu behandeln.
Ein festes gemeinsames Schema wird bei unregelmäßigen Daten oder einfachen Abfragen zu einer echten Einschränkung
Das feste Tabellenschema einer relationalen Datenbank verlangt, dass jeder Datensatz desselben Typs exakt dieselbe Struktur teilt, was zu einer echten, praktischen Einschränkung wird, wenn Daten von Natur aus unregelmäßig sind – ein Produktkatalog etwa, in dem verschiedene Produkttypen tatsächlich unterschiedliche Attribute haben – oder wenn das primäre Ziel einer Anwendung extrem schnelle, einfache Abfragen sind statt komplexer relationaler Abfragen über viele separate Tabellen hinweg.
Drei grundlegend unterschiedliche NoSQL-Modelle existieren, weil sie drei grundlegend unterschiedliche Probleme lösen
Dokumentendatenbanken eignen sich gut für unregelmäßige, in sich geschlossene Datensätze, da sie jeden davon als flexibles Dokument speichern, ohne jeden Datensatz in eine identische, gemeinsame Form zu zwingen. Key-Value-Stores eignen sich für extrem schnelle, einfache Abfragen, wie einen Session-Cache, bei dem nie etwas Komplexeres nötig ist, als einen Wert über genau einen Schlüssel abzurufen. Graphdatenbanken eignen sich für Daten, bei denen die Beziehungen zwischen Datensätzen, nicht nur die Datensätze selbst, das sind, was tatsächlich effizient abgefragt werden muss – die Verbindungen eines sozialen Netzwerks sind dafür das gängigste Beispiel.
Was wir noch nicht genau wissen
Dass NoSQL-Datenbanken die gemeinsame Struktur des relationalen Modells gegen ein zu einem bestimmten Problem passendes Modell eintauschen, ist gut etablierte, unumstrittene Datenbanktechnik. Ein wirklich lebendiger, aktiv diskutierter technischer Kompromiss ist hingegen, für eine gegebene reale Anwendung das richtige NoSQL-Modell zu wählen – oder stattdessen eine relationale Datenbank –, denn eine Dokumentendatenbank kann am Ende relationale Joins benötigen, die unbeholfen im Anwendungscode nachgebaut werden müssen, sobald die Daten einer Anwendung mit der Zeit tatsächlich stärker vernetzt werden, und im Voraus vorherzusagen, ob das für eine bestimmte neue Anwendung passieren wird, bleibt eine echte, unvollkommene Ermessensentscheidung statt etwas, das eine feste Regel klären könnte.
Das gehört zu NoSQL-Modelle (Dokument, Key-Value, Graph), einem von sieben Themen in Datenbanken, einer von sieben Domänen in Informatik, einem von siebzehn Fächern, die die App abfragen kann.