Moin,

was sind denn strukturiert vorliegende Daten im RAM?

Genau das was da steht. Strukturen (zum Beispiel C-structs) die im RAM liegen und untereinander verpointert sind.

Ein RDBMS haelt Daten strukturiert im RAM

Ja, aber mit einer fast fest vorgegebenen Struktur die evt. nicht dem Einsatzzweck optimal angepasst ist.

ein Flatfile-System (eher) nicht.

Es geht auch nicht um ein Flatfile-System, sondern um strukturierte Daten im RAM. Ob man die dann zu Langzeitspeicherzwecken in eine Datei serialisiert oder woanders hin ist weitestgehend egal.

Wenn auf eine groessere Zahl Entitaeten zugegriffen wird, die miteinander in bestimmten Beziehungen stehen und diese Beziehungen werden abgefragt, dann ist das RDBMS natuerlich schneller. (Bei "Eintabellendatenzugriffen" natuerlich nicht.)

In diesem Fall nicht, d.h. die Aussage ist nicht allgemeingültig. Vergleichen wir doch mal losgelöst zwei annähernd optimale (unter den jeweiligen Bedingungen) Implementierungen (ich habe ausdrücklich keine detaillierte Ahnung was hier wirklich passiert, kann mir aber vorstellen was ich machen würde) unter der gemeinsamen Aufgabe "einen Threadbaum darstellen".

Datenstrukturen im RAM: Der Daemon kriegt den Auftrag und eine Threadnummer genannt. Er sucht den Anfang des jeweiligen Threads im RAM (ob über einen Index oder binäre Suche ist fast schon egal), dort findet er eine Datenstruktur mit den nötigen Informationen für das erste Posting, sowie eine Liste mit Pointern zu den direkten Kindpostings. Er macht jetzt einfach Tiefensuche auf den Pointern und findet so immer mehr Kindpostings die er direkt schon zurückgeben kann (da sie implizit in der richtigen Reihenfolge auftauchen). Das ganze ist 'straight forward' und enthält eigentlich nur Speicherzugriffe über Pointer sowie halt soviele Kopieraktionen wie notwendig sind um die abgefragten Daten zurückzugeben.

RDBMS: Der Datenbankserver kriegt eine Abfrage. Die muß er jetzt erstmal parsen. Wenn er sie geparst hat optimiert er vielleicht noch ein bisschen, sowie macht sich fertig auf die nötigen Tabellen zuzugreifen. Über einen Indexzugriff findet er vielleicht auch das erste Posting ganz leicht. Nehmen wir einfach mal an zu jedem Posting würden in einer separaten Tabelle auch noch alle direkten Kinder aufgelistet. Dann muß er trotzdem noch die ID des ersten Postings nehmen, in der Tabelle nachsehen welche IDs die Kinder haben und die Kinder über IDs (Indexzugriff) raussuchen, usw. (Die Alternative wäre wenn jedes Kind nur die ID seines Vaters im Datensatz hat, was aber auch nicht schneller wäre, eher im Gegenteil.)
Wenn man kein DMBS mit stored procedures und sub-selects o.ä. einsetzt muss ausserdem die rekursive Suche durch den Anfragenden Prozess angestoßen werden was viele, viele Kontextwechsel und häufiges erneutes Anstoßen des Query-Parsers und Optimierers bedeuten würde.
Am Ende muss der Datenbankserver (oder der anfragende Prozess) das Ergebnis ggbf. noch sortieren (und vielleicht die passenden Vater-Kind-Beziehungen zur Einrückung rekonstruieren).
Das ganze ist reichlich verzwackt und enthält nicht einen einzigen direkten Speicherzugriff, sondern immer nur Indirektionen über IDs. Das kann man zwar über Indices vergleichsweise(!) effizient implementieren, es ist aber mindestens um eine Größenordnung langsamer.

(P.S.: Ludger: Sollte ich zu viele Fremdwörter wie Datenstruktur, Tiefensuche oder Pointer verwendet haben: Keine Angst, die müssten alle bei Wikipedia erklärt sein.)