Sind die schneller && genauso stabil wie PostgerSQL oder Oracles DB

[GUI-Master]

mich würd interessieren, ob das NoSQL-Zeug auch für den professionellen Einsatz geeignet ist. Klar haben die weniger Funktionen, aber kann diese DB genauso schnell simple Anfragen bearbeiten wie ausgereifte SQL-Systeme?

Was ist überhaupt der Vorteil von denen. SQL ist zugegebener Maßen nicht trivial - der NoSQL-Syntax ist jedoch noch komplizierter und uneinheitlicher.

[Sqlly]

SQL ist für Datensätze geeignet, die aus großen einheitlichen Datensätzen bestehen, über die komplizierte Anfragen gefahren werden. Bei Banken, Versicherungen, statistischer Wissenschaft der Fall.

Die seit einiger Zeit aufkommenden KeyValueStores werden anders benutzt. Sie sind besser für große Mengen nicht einheitlicher Datensätze, über die keine komplizierten Algorithmen gefahren werden müssen. Wie bei Webseiten häufig der Fall. Alle Anwendungen, in denen die Datensätze nur gesucht und aus der Datenbank ausgelesen werden müssen sind besser geeignet für NoSQL.

Und ja: die Dinger sind _dabei_ schneller und besser als Postgres oder Oracel. Die Datenbanken sind zumeist auch kleiner und lassen sich besser verteilt vorhalten und syncen. Syncen bei SQL Datenbanken ist übrigens der Grund, warum manche von den Dingern so enorm teuer sind (weil das dort nicht trivial ist).

[Die schlaue Post]

Siehe auch anderes Posting.

Kunden haben diverse Kontakt-Möglichkeiten: EMail, Skype, ICQ, Jabber, Facebook, SecondLife, de-Mail-1, de-Mail-2 ... und natürlich diverse Telefonnnummern per Festnetz und Mobil.
Wenn Du für jedes davon eine Spalte anlegst, sind diese meist zu 90% oder noch mehr leer. Oder separate Tabellen. Das nervt auch.

Und ein Kunde hat möglicherweise mehrere Telefonnummern für verschiedene Zwecke. Und für Email-Adressen gilt dasselbe.

D.h. beim Webshop würde man den Katalog in einer normalen SQL-Datenbank halten, aber die Kunden-Kontakte vielleicht per Key-Value. Andere Kundendaten wie Liefer-Adressen, Bestellungen usw. wieder normal in einer SQL-Datenbank.
Für einen kleinen WebShop wäre das overkill. Also dort nur Email und kein ICQ und nur eine Telefonnummer für SMS o.ä. .

Amazon hingegen würde das vielleicht machen und Kunden die es wollen, genau über den Lieferstatus informieren. Und zwar mit allen Diensten die aktuell nicht zu speziell sind. Gleiches für die Post, wenn sie schlau ist.

Einheitliche und gleichartig organisierbare Daten sind wohl meist besser für SQL.
Wenn aber großteile nur NULL-Felder enthalten, oder man viele viele viele Tabellen hat, sind andere Datenbanken vielleicht besser. Auch, wenn man spezielle Abfragen wünscht, wo SQL-Datenbanken nicht so gut performen.
Bei Data Warehousing werden auch die Summen über die Kassenbons, die Tagesverkäufe als Summen usw. vorgehalten, um alles miteinander vergleichen zu können, ohne z.B. alle Kassenbons aller Wochenendverkäufe aller Filialen untereinander vergleichen zu können und dafür alle Kassenbons heraussuchen und aufaddieren zu müssen. Also hat man Slices und Summen, Min, Max, Durchschnitte usw. und kann die direkt heraussuchen. Das ist totale Redundanz. Diese gibts normalerweise bei SQL nicht.

Dazu ist aber auch zu sagen, das Oracle usw. sich die Butter nicht vom Brot nehmen lassen wollen. Daher können normale SQL-Datenbanken ja inzwischen oft XML oder bieten auch DataWarehousing-Funktionen.

Vielleicht werden SQL-Datenbanken auch mal schlau und man kann problemlos mehrere Emails pro Kunden halten oder diverse Kontakt-Möglichkeiten, ohne das die Size explodiert. Weil die Datenbank dünn besetzte Spalten automatisch in sub-tabellen oder gap-blocks auslagert ohne das der Anwender/Admin mehr machen muss, als es zu erlauben und sich statistisch den Erfolg aufzeigen zu lassen.

Im Prinzip sollte sich sowas auch über Wikipedia finden lassen.

[GUI-Master]

Also lesen ist zumindest bei kleinen db schneller?

Warum erinnert mich das nur an Berkeley DB? Die sind ja jetzt auch auf die SQL-Schiene gewechselt (vgl. http://www.golem.de/1003/74077.html).

PostgerSQL ist kostenfrei und so leistungsstark wie die »so enorm Teueren« (global betrachtet).

Statische Websites währen noch schneller - ansonsten soll also NoSQL besser sein? Welches Produkt genau? - C++ und andere Programmiersprachen währen in diesem Fall ja noch besser, wenn ich Keys in Values wandeln will (vgl. Hash-Tabellen, assoziative arrays o.ä.).

Was mach ich denn mit den Adress- && Produkt-DB`s? Dafür scheint das NoSQL ja nicht zu taugen?

[Perl 6 rulez]

Normales SQL kannst Du per Hibernate u.ä. automatisch auf SQL umsetzen lassen. Da lässt man die klassische Datenbank weiter mit SQL laufen.

Aber Zusatzkrams kann man per NoSQL regeln.
Vielleicht nutzt man es auch nur für die Webserver-Logfiles (ohne die Hits für Gif, .js usw.) und Bewegungsprofile der Benutzer oder andere speziellen Dinge.

Und wenn Du mit Hashes auskommst, brauchst Du auch keine Replikation der Datenbanken. Also hast Du wenige Besucher oder gute Clients die nicht ständig alle Daten neu laden.

Lies besser die Artikel der Wikipedia. Ständig alles erklären ist hier wohl für einen einzigen Interessenten nicht effizient.
In einer der letzten cts (Nr.15/2010) waren NoSQL Datenbanken drin. Ich war bisher zu faul, den Artikel zu lesen.