... schade dass so viele Hoster noch kein MongoDB anbieten. Stattdessen hat man eben nach wie vor nur MySQL, wenn man Glück hat evtl. auch Postgres. Ich habe mal einen Anbieter mit CouchDB gesehen, das wars dann aber schon. Schade, dass man das nur mit eigenem root-Server bekommen kann. Viele 0815 Applikationen ließen sich mit Mongo leichter umsetzen.
Zudem käme dann auch mal Bewegung in das populistische PHP+MySQL Buzzing.
"Viele 0815 Applikationen ließen sich mit Mongo leichter umsetzen."
Naja, das ist so eine Sache. Einfach und leicht ist, was bekannt ist. Und das Wissen zu SQL und co. ist weit verbreitet, das zu MongoDB und co. nicht. Da zudem noch jede der so gerne "NoSQL" genannten Datenbanken auch noch sein eigenes Süppchen kocht, dauert es eben auch bis das Wissen verbreitet ist.
Von MySQL ist der Weg zu PostgreSQL eben eher kurz, MongoDB erfordert eine ganz andere Herangehensweise.
Ich glaube daher auch nicht das sich MongoDB (oder eine andere NoSQL DB) ähnlich wie MySQL verbreiten wird.
Zudem lassen sich viele Dinge mit einer SQL DB ebenfalls Problemlos lösen, wenn es um 08/15 Apps geht. Dank ORM und co. ist die Handhabung einer SQL DB nicht gerade komplex. Dafür ist das Feld Relationale DB sehr gut erforscht.
Zudem lassen sich viele Dinge mit einer SQL DB ebenfalls Problemlos lösen, wenn es um 08/15 Apps geht. Dank ORM und co. ist die Handhabung einer SQL DB nicht gerade komplex. Dafür ist das Feld Relationale DB sehr gut erforscht.
Das stimmt natürlich auch wieder. Ich finde SQL-DBs auch durchaus für nützlich; kommt imho doch stark auf den Anwendungsfall an.
Imho ist verhält sich das analog zu imperativer und funktionaler Programmierung. Theoretisch kann man ein Problem immer von einem ins andere transferieren. Aber je nach Problem gestaltet sich die Modellierung eben mal in diesem und mal in jenem einfacher und plausibler.
Von ach wer bin ich denn gleich ma am Fr, 18. März 2011 um 09:28 #
Hab keine Angst vor SQL. Such Dir paar Tutorials, die mehr als Select, Insert, Update abdecken, und Du wirst Deine Freude haben. Am Ende liegen die Daten immer in Dateien auf der Festplatte. Es ist piepegal, wie man die Engine nennt und nach welchem Prinzip sie arbeitet. Ich glaube, mit Fortschreiten eines Projektes wird man eher an den Punkt kommen, wo man von NoSQL zu SQL wechseln sollte, statt umgekehrt.
Je nach Szenario wird es eher grauenhaft. Vor allem wenns um Skalierung geht sind Relationale SQL DBs eigentlich eher ungeeignet. Der zentrale Datenspeichert skaliert immer am schlechtesten, und die vielen Verbindungen der Tabellen in Relationalen DBs machen es erst richtig schwer. Solche DBs sind für vieles wirklich toll, aber wenn man schnell und stark skalieren will ist es die Hölle.
Vieles, was ich heute NoSQL nennt, hat den Ansatz dieses Ungleichgewicht in der Skalierung von Anwendungen so zu verändern, das auch die Datenschicht skalierbarer wird.
Natürlich können SQL DBs sehr hoch skalieren, oftmals aber unter weglassen der besten Features der SQL DBs, oder durch extrem teure Hardware, wobei auch diese ihre Grenzen hat.
Du solltest zudem keine Angst vor z.B. MongoDB haben. Schau dir mal die Tutorials an, dann wirst du erkennen das eine Document Oriented DB ganz andere Lösungen erlaubt als eine Relationale. Gerade bei komplexen, großen Projekten mit vielen Abhängigkeiten können Document Oriented DBs viele Probleme lösen bzw. die Arbeitsweise stark vereinfachen.
Es scheint eher umgekehrt zu sein wie du glaubst: Man startet dank ORM und co. heute sehr leicht mit SQL DBs, aber wenn das Projekt wächst sind spezialisiertere DBs besser geeignet. Wenn man genau weiss was man braucht, und nur dann sind alternativen zu allgemeinen Relationalen DBs wirklich passend, kann man seine Datenspeichert damit deutlich optimieren.
Nicht zu vergessen das diese so unschön NoSQL genannten DBs oft wichtige Features haben, die Relationalen DBs nicht bieten. Von JSON-artiger Datenspeicherung, über Map/Reduce in der Abfragelogik, bis Autosharding, einfache Master/Master Replikation selbst ohne dauerhafte Verbindung der DBs usw. Manches geht in manchen Relationalen DBs, aber oft nur mit großem Aufwand, als unschöner Hack oder mit vielen Nachteilen die bei spezialisierten DBs nicht gegeben sind.
Wie hoch z.B. MySQL skaliert sind man wiederum an Facebook. Wenn man aber auch weiss das MySQL dort nur als Key/Value Store dient, sieht man auch das dabei fast alles verloren geht, was überhaupt einen Wert bei Relationalen DBs hat.
Es heisst ja "not only SQL" - das impliziert doch irgendwie, dass sie SQL haben und noch was dazu, oder? haben sie aber nicht. Warum bauen die nicht einfach ein performantes SQL-Frontend auf ihre Mongo-DB - dann können sie im direkten Vergliech zeigen, ob sie besser sind. Ansonsten: Willkommen im proprietären, nie wieder portierbaren Gefrickel der Vor-Relationalen Datenbanken.
Warum bauen die nicht einfach ein performantes SQL-Frontend auf ihre Mongo-DB - dann können sie im direkten Vergliech zeigen, ob sie besser sind.
Ganz einfach weil ein solches Frontend nun einmal nicht performant wäre, selbst wenn man es schafft, die wichtigen Kommandos und tieferliegenden Eigenschaften von SQL zu mappen.
Du forderst etwas komplett sinnloses! Man vergleicht ein Elektroauto auch nicht dadurch mit einem auf Verbrennungsmotor setzenden Automobil dadurch, dass man dem E-Auto einen Benzin getriebenen Generator einbaut, der den Strom liefert.
Akzeptiere einfach, dass die Konzepte sich unterscheiden; ein Vergleichstest kann man nur mit einer BlackBox in der "Mitte" durchführen. Sprich, Du definierst Deine Basisdaten, und das Ergebnis, welches Du haben möchtest und prüfst dann eben mögliche Parameter wie Ausführungsgeschwindigkeit, Komplexität der Abfrage, usw. ab.
SQL-basierte Lösungen haben durchaus ihre Berechtigungen; NoSQL-basierte aber eben auch. Man muss da keinen Glaubenskrieg anzetteln, da es einfach auch viel auf persönliche Befindlichkeiten ankommt.
Das sehe ich nicht so - wenn wir mal in die Tiefe der DB-Geschichte blicken: Fast alle alten DBs fingen mal als No-SQL-DBs (No hier im Sinne von Not) an - waren oft auch keine relationalen DBs sondern z.B. hierarchische - und wurden dann im Lauf der Zeit um SQL-Fähigkeiten erweitert! Und es ist auch weder unmöglich; ja noch nicht mal eine große Kunst, das abzubilden - halt (nicht gleich) nicht mit 100 % der Features, schon klar. /Z.B. halt dann ohne joins und ohne ACID oder ein geordnetes Schema - Wer es nicht braucht, braucht es nicht - wer alles in den gleichen Eimer stopfen will, der solls ...).
Es geht hier also um mehrere Sachen: a) relational gegen nicht-relational. b) ACID gegen "best-effort" c) Ein standardisiertes Interface.
Das ganze NoSQL zu nennen, war ist ein riesengroßer Blödsinn (schon allein die Kehrtwende von No zu not only - was für Trottel). Und es hat nichts mit SQL zu tun (höchstens indirekt, weil SQL halt die relationalen Features gut abdeckt), sondern mit Relationalität und ACID.
Die hätten das ganze vielleicht No-Acid oder No-Relational oder noch besser (weil positiv ausgedrück) "Max-Performance-DBs" nennen sollen.
Und was kommt dabei heraus? Jemand fordert mit dem Brustton der Überzeugung, dass NoSQL-DBs kein SQL kennen KÖNNEN. Hahaha...
Der Begriff No-SQL wird sicherlich auch bald vom Tisch sein, beschreibt er doch immerhin nichts wesentliches der Datenbanken.
MongoDB bezeichnet sich selbst auch eigentlich als document-oriented database. Das ist wiederum absolut korrekt. Zwar könnte man, um die Features von MongoDB zu nutzen, eine Abwandlung von SQL sicherlich entwickeln, allerdings brächte das recht wenig, vor allem sicher am Ende nicht einheitlich im Vergleich zu anderen Datenbanken, auch nicht zu Documentorientierten.
Und was kommt dabei heraus? Jemand fordert mit dem Brustton der Überzeugung, dass NoSQL-DBs kein SQL kennen KÖNNEN. Hahaha...
Das sagt derjenige, der weiter oben ja durchaus zu recht erkannt hatte:
Es geht hier also um mehrere Sachen: a) relational gegen nicht-relational. b) ACID gegen "best-effort" c) Ein standardisiertes Interface.
Dann erkläre Du mir doch mal, wie sich SQL in diese Infrastruktur einpassen soll? Selbst ein SELECT ... FROM ist ja dabei sinnlos. Was sollte man sinnvoller Weise bei "from" angeben?
Ich bleibe dabei: Du willst einen Vergleich auf der falschen Ebene! Darum gings bei meinem Beitrag, nicht um Namensgebung o.ä.
... schade dass so viele Hoster noch kein MongoDB anbieten. Stattdessen hat man eben nach wie vor nur MySQL, wenn man Glück hat evtl. auch Postgres. Ich habe mal einen Anbieter mit CouchDB gesehen, das wars dann aber schon. Schade, dass man das nur mit eigenem root-Server bekommen kann. Viele 0815 Applikationen ließen sich mit Mongo leichter umsetzen.
Zudem käme dann auch mal Bewegung in das populistische PHP+MySQL Buzzing.
"Viele 0815 Applikationen ließen sich mit Mongo leichter umsetzen."
Naja, das ist so eine Sache. Einfach und leicht ist, was bekannt ist. Und das Wissen zu SQL und co. ist weit verbreitet, das zu MongoDB und co. nicht.
Da zudem noch jede der so gerne "NoSQL" genannten Datenbanken auch noch sein eigenes Süppchen kocht, dauert es eben auch bis das Wissen verbreitet ist.
Von MySQL ist der Weg zu PostgreSQL eben eher kurz, MongoDB erfordert eine ganz andere Herangehensweise.
Ich glaube daher auch nicht das sich MongoDB (oder eine andere NoSQL DB) ähnlich wie MySQL verbreiten wird.
Zudem lassen sich viele Dinge mit einer SQL DB ebenfalls Problemlos lösen, wenn es um 08/15 Apps geht. Dank ORM und co. ist die Handhabung einer SQL DB nicht gerade komplex. Dafür ist das Feld Relationale DB sehr gut erforscht.
Imho ist verhält sich das analog zu imperativer und funktionaler Programmierung. Theoretisch kann man ein Problem immer von einem ins andere transferieren. Aber je nach Problem gestaltet sich die Modellierung eben mal in diesem und mal in jenem einfacher und plausibler.
Hab keine Angst vor SQL. Such Dir paar Tutorials, die mehr als Select, Insert, Update abdecken, und Du wirst Deine Freude haben.
Am Ende liegen die Daten immer in Dateien auf der Festplatte. Es ist piepegal, wie man die Engine nennt und nach welchem Prinzip sie arbeitet.
Ich glaube, mit Fortschreiten eines Projektes wird man eher an den Punkt kommen, wo man von NoSQL zu SQL wechseln sollte, statt umgekehrt.
"und Du wirst Deine Freude haben."
Je nach Szenario wird es eher grauenhaft. Vor allem wenns um Skalierung geht sind Relationale SQL DBs eigentlich eher ungeeignet. Der zentrale Datenspeichert skaliert immer am schlechtesten, und die vielen Verbindungen der Tabellen in Relationalen DBs machen es erst richtig schwer. Solche DBs sind für vieles wirklich toll, aber wenn man schnell und stark skalieren will ist es die Hölle.
Vieles, was ich heute NoSQL nennt, hat den Ansatz dieses Ungleichgewicht in der Skalierung von Anwendungen so zu verändern, das auch die Datenschicht skalierbarer wird.
Natürlich können SQL DBs sehr hoch skalieren, oftmals aber unter weglassen der besten Features der SQL DBs, oder durch extrem teure Hardware, wobei auch diese ihre Grenzen hat.
Du solltest zudem keine Angst vor z.B. MongoDB haben. Schau dir mal die Tutorials an, dann wirst du erkennen das eine Document Oriented DB ganz andere Lösungen erlaubt als eine Relationale. Gerade bei komplexen, großen Projekten mit vielen Abhängigkeiten können Document Oriented DBs viele Probleme lösen bzw. die Arbeitsweise stark vereinfachen.
Es scheint eher umgekehrt zu sein wie du glaubst:
Man startet dank ORM und co. heute sehr leicht mit SQL DBs, aber wenn das Projekt wächst sind spezialisiertere DBs besser geeignet. Wenn man genau weiss was man braucht, und nur dann sind alternativen zu allgemeinen Relationalen DBs wirklich passend, kann man seine Datenspeichert damit deutlich optimieren.
Nicht zu vergessen das diese so unschön NoSQL genannten DBs oft wichtige Features haben, die Relationalen DBs nicht bieten. Von JSON-artiger Datenspeicherung, über Map/Reduce in der Abfragelogik, bis Autosharding, einfache Master/Master Replikation selbst ohne dauerhafte Verbindung der DBs usw.
Manches geht in manchen Relationalen DBs, aber oft nur mit großem Aufwand, als unschöner Hack oder mit vielen Nachteilen die bei spezialisierten DBs nicht gegeben sind.
Wie hoch z.B. MySQL skaliert sind man wiederum an Facebook. Wenn man aber auch weiss das MySQL dort nur als Key/Value Store dient, sieht man auch das dabei fast alles verloren geht, was überhaupt einen Wert bei Relationalen DBs hat.
Es heisst ja "not only SQL" - das impliziert doch irgendwie, dass sie SQL haben und noch was dazu, oder?
haben sie aber nicht.
Warum bauen die nicht einfach ein performantes SQL-Frontend auf ihre Mongo-DB - dann können sie im direkten Vergliech zeigen, ob sie besser sind.
Ansonsten: Willkommen im proprietären, nie wieder portierbaren Gefrickel der Vor-Relationalen Datenbanken.
Du forderst etwas komplett sinnloses! Man vergleicht ein Elektroauto auch nicht dadurch mit einem auf Verbrennungsmotor setzenden Automobil dadurch, dass man dem E-Auto einen Benzin getriebenen Generator einbaut, der den Strom liefert.
Akzeptiere einfach, dass die Konzepte sich unterscheiden; ein Vergleichstest kann man nur mit einer BlackBox in der "Mitte" durchführen. Sprich, Du definierst Deine Basisdaten, und das Ergebnis, welches Du haben möchtest und prüfst dann eben mögliche Parameter wie Ausführungsgeschwindigkeit, Komplexität der Abfrage, usw. ab.
SQL-basierte Lösungen haben durchaus ihre Berechtigungen; NoSQL-basierte aber eben auch. Man muss da keinen Glaubenskrieg anzetteln, da es einfach auch viel auf persönliche Befindlichkeiten ankommt.
Das sehe ich nicht so - wenn wir mal in die Tiefe der DB-Geschichte blicken:
Fast alle alten DBs fingen mal als No-SQL-DBs (No hier im Sinne von Not) an - waren oft auch keine relationalen DBs sondern z.B. hierarchische - und wurden dann im Lauf der Zeit um SQL-Fähigkeiten erweitert!
Und es ist auch weder unmöglich; ja noch nicht mal eine große Kunst, das abzubilden - halt (nicht gleich) nicht mit 100 % der Features, schon klar.
/Z.B. halt dann ohne joins und ohne ACID oder ein geordnetes Schema - Wer es nicht braucht, braucht es nicht - wer alles in den gleichen Eimer stopfen will, der solls ...).
Es geht hier also um mehrere Sachen:
a) relational gegen nicht-relational.
b) ACID gegen "best-effort"
c) Ein standardisiertes Interface.
Das ganze NoSQL zu nennen, war ist ein riesengroßer Blödsinn (schon allein die Kehrtwende von No zu not only - was für Trottel). Und es hat nichts mit SQL zu tun (höchstens indirekt, weil SQL halt die relationalen Features gut abdeckt), sondern mit Relationalität und ACID.
Die hätten das ganze vielleicht No-Acid oder No-Relational oder noch besser (weil positiv ausgedrück) "Max-Performance-DBs" nennen sollen.
Und was kommt dabei heraus? Jemand fordert mit dem Brustton der Überzeugung, dass NoSQL-DBs kein SQL kennen KÖNNEN. Hahaha...
Der Begriff No-SQL wird sicherlich auch bald vom Tisch sein, beschreibt er doch immerhin nichts wesentliches der Datenbanken.
MongoDB bezeichnet sich selbst auch eigentlich als document-oriented database. Das ist wiederum absolut korrekt. Zwar könnte man, um die Features von MongoDB zu nutzen, eine Abwandlung von SQL sicherlich entwickeln, allerdings brächte das recht wenig, vor allem sicher am Ende nicht einheitlich im Vergleich zu anderen Datenbanken, auch nicht zu Documentorientierten.
Ich bleibe dabei: Du willst einen Vergleich auf der falschen Ebene! Darum gings bei meinem Beitrag, nicht um Namensgebung o.ä.