Hi,
also wir nutzen beides für vollkommen verschiedene Dinge.
In NoSQL pumpen wir alles was einem DBMS Probleme macht.

Das sind:
* Daten die zu groß für einen Rechner sind
* Daten die kontrolliert verteilt sein müssen (z.B. Uploads, die man nicht über die MySQL Replikation schicken will)
* Häufig fragmentierende Daten
* Extrem häufig beschriebene Daten (womöglich noch gleichzeitig gelesen? Willkommen Table Locking)

Naja, was bleibt übrig... genug
Im normalen DBMS liegen dann die Standard Modeldaten. Transaktionssichere Prozesse (z.B. Payment)

Wir nutzen übrigens im Moment Redis als NoSQL Datenbank, habe heute mal einen Benchmark veröffentlicht: [wiki]Memcached VS Redis - Vergleich der PHP Clients[/wiki]
Ich persönlich bin aber auch sehr in anderen Technologien interessiert - in zwei Wochen besuche ich zum ersten mal das Hadoop Usergroup Treffen

Lg

naja, hängt von der Anwendung ab.
Standard Model Daten sind für mich "User", "Invoice", CMS Daten, ...

Die Facebook Userinformationen fallen sowieso wieder unter die Kategorie: "Passen nicht auf einen Computer".
Aber du hast Recht - das ist ein gutes Beispiel das zeigt wie vorteilhaft das "lose" Schema ist.

Die Information user<>email müsste übrigens beidseitig indexiert werden, damit du nach E-Mail Adressen suchen kannst. Im RDMS kein Problem, bei NoSQL... ?

Das hängt vom NoSQL System ab. Die meisten NoSQL Systeme sind Key Value Datenbanken. Somit sind alle Schlüssel indexiert...

Solr ist ein Suchserver der auf dem "NoSQL Dateisystem" Hadoop problemlos einen Lucene Index durchsucht. Es gibt also auch Lösungen für eine bequeme Indexierung im NoSQL Bereich.
Aber vergleich das mal mit einem RDBMS - es ist doch letztendlich genau kompliziert, wenn du ein RDBMS System selber entwickeln willst und Rot- Schwarzbäume selber implementieren musst.

NoSQL ist meistens viel Anwendungsoptimierter.. Für die Indexierung eignet sich Lucene, für Attachments eignet sich CouchDB, usw