Michael Schuerig schrieb am 28. Juni 2010 03:08
> Daten sollten auch konsistent sein und bleiben. Genau da liegt der
> Kern des relationalen Modells.
Das ist nur ein Aspekt, und in vielen Fällen nicht der wichtigste. In
der dreckigen Praxis wird viel mit Denormalisierung, händischen Joins
im Hautpspeicher etc. gearbeitet.
Es gibt einen weiteren Aspekt bei relationalen DBs, der mindestens
ebenso wichtig ist: Indizes, speziell B+-Bäume.
Und nun kommt hinzu, dass du bei klassischen relationalen DBs immer
beides hast: Baumbasierte Indizes für schön schnelle Queries und
Views, dies aber immer quasi verheiratet mit einem relativ starren
Datenschema, das vielleicht "konsistent" ist, aber nur schwer bis
garnicht an die tatsächlich anwendungsspezifischen Erfordernisse an
die Datenhaltung anpassbar ist. In vielen Fällen muss man seine
Anwendungsdatenstrkturen erst umständlich (und mit Reibungsverlusten)
auf SQL abbilden, und hinterher ist die SQL-Datenbank vielleicht noch
"in sich" konsistent, aber nicht mehr konsistent zu dem Datenmodell,
das man eigentlich in seiner Anwendung haben will.
Und ich schätze, genau aus dieser Beobachtung und Motivation heraus
sind so Sachen wie CouchDB entstanden. Baumbasierten Indizes auf der
einen Seite und hochstrukturierte und vom System (statt der
Anwendung) konsistent gehaltenen Datendefinitionen auf der anderen
Seite sind i.W. orthogonale Konzepte; ihre "Verheiratung" im Rahmen
von SQL/DDL ist nicht unbedingt notwendig. Und deswegen haben die
NoSQL-Leute sich gedacht, wir dröseln die Verheiratung auf, lassen
den User umstandslos beliebige Daten "schemalos" speichern und machen
nur noch die Indizierung im System, wobei wir die Abbildung der Daten
auf die Indizes einfach frei programmierbar machen
(map/reduce-Funktionen).