Für mich neben Gimp, Blender usw. einer der leuchtenden Sterne am OpenSource Himmel. Und vor allem eines: stabil! Ich frage mich bis heute noch, warum so viele auf MySQL sitzen bleiben. Das hat mich schon VOR der Oracle Übernahme nicht mehr sonderlich überzeugt, nachdem ich Postgres nur ein bisschen angeschnitten habe.
"Ich frage mich bis heute noch, warum so viele auf MySQL sitzen bleiben. "
Das ist relativ leicht zu erklären, vor allem wenn man wie ich beides verwendet: MySQL ist einfach wesentlich leichter zu bedienen, es setzt weniger Wissen vorraus, und die Lösungen aus dem MySQL Umfeld sind oft deutlich pragmatischer gehalten, und leichter zu nutzen.
Nehmen wir die Replikation: MySQL hat sie integriert, bei PostgreSQL musste man unter mehreren Lösungen wählen, von denen einige zudem auf nicht gerade banalen Triggern und Stored Procedures basieren. Das sind Konzepte, mit denen sich ein MySQL User auch beim Thema Replikation nicht auseinander setzen muss.
Beispiel PostGIS: PostGIS ist sehr mächtig, aber das Konzept wie man es aufsetzt ist für Anfänger ein Buch mit sieben Siegeln. Template? In einer DB? Und was machen die ganzen SQL kommandos da eigentlich. Und wie wirkt das in meiner DB? MySQL, mit deutlich schlechterem Support in diesem Bereich, bietet fertige Felder an, die man einfach nutzen kann, ohne viel Vorbereitung. Was bei PostGIS dutzende komplexe Komandos sind, ist bei MySQL schon (wenn auch deutlich schlechter) fertig.
Auch das Userkonzept von PostgreSQL dürfte viele verwirren. Den Zusammenhang von lokalen Usern zu PostgreSQL Usern dürfte nicht jeder sofort verstehen, zumal dies auch eine Frage der Konfiguration ist. MySQL ist hier einfacher aufgestellt, wenn auch weniger flexibel, aber eben so, wie es die meisten brauchen.
PostgreSQL krankt, meiner Meinung nach, an seiner Komplexität und seinen Möglichkeiten, die von vielen gar nicht gebraucht werden.
Wenn eine andere Lösung einfacher zu nutzen ist, und die Funktionen bietet die man braucht, dann wird diese meistens auch genutzt.
Wie man so schön sagt: MySQL ist in 99% der Fälle einfach gut genug. Und einfach zu nutzen.
Wenn man aber, wie in meinem Fall, die speziellen Funktionen von Postges braucht, dann sieht die Sache natürlich anders aus. Dann ist MySQL eben nicht mehr gut genug, und fällt alleine wegen mangelnder Features aus der Auswahl raus.
Die Feature-Liste hört sich gut an! Das einzige was ich mich frage, ist, was einen UNION DISTINCT von einem normalen UNION unterschiedet? Das ist doch der Normalfall - ansonsten gibts ja UNION ALL?
Übrigens halte ich das mit UNION für die schwerste Design-Fehlentscheidung von den "Machern" von SQL, hier den Weg anders rum als sonst zu gehen - falls das wer erklären kann, würde ich mich sehr freuen, das würde mich echt interessieren!
Für mich neben Gimp, Blender usw. einer der leuchtenden Sterne am OpenSource Himmel. Und vor allem eines: stabil! Ich frage mich bis heute noch, warum so viele auf MySQL sitzen bleiben. Das hat mich schon VOR der Oracle Übernahme nicht mehr sonderlich überzeugt, nachdem ich Postgres nur ein bisschen angeschnitten habe.
Ohne Gimp würde ich dir zustimmen.
"Ich frage mich bis heute noch, warum so viele auf MySQL sitzen bleiben. "
Das ist relativ leicht zu erklären, vor allem wenn man wie ich beides verwendet: MySQL ist einfach wesentlich leichter zu bedienen, es setzt weniger Wissen vorraus, und die Lösungen aus dem MySQL Umfeld sind oft deutlich pragmatischer gehalten, und leichter zu nutzen.
Nehmen wir die Replikation: MySQL hat sie integriert, bei PostgreSQL musste man unter mehreren Lösungen wählen, von denen einige zudem auf nicht gerade banalen Triggern und Stored Procedures basieren. Das sind Konzepte, mit denen sich ein MySQL User auch beim Thema Replikation nicht auseinander setzen muss.
Beispiel PostGIS: PostGIS ist sehr mächtig, aber das Konzept wie man es aufsetzt ist für Anfänger ein Buch mit sieben Siegeln. Template? In einer DB? Und was machen die ganzen SQL kommandos da eigentlich. Und wie wirkt das in meiner DB?
MySQL, mit deutlich schlechterem Support in diesem Bereich, bietet fertige Felder an, die man einfach nutzen kann, ohne viel Vorbereitung. Was bei PostGIS dutzende komplexe Komandos sind, ist bei MySQL schon (wenn auch deutlich schlechter) fertig.
Auch das Userkonzept von PostgreSQL dürfte viele verwirren. Den Zusammenhang von lokalen Usern zu PostgreSQL Usern dürfte nicht jeder sofort verstehen, zumal dies auch eine Frage der Konfiguration ist. MySQL ist hier einfacher aufgestellt, wenn auch weniger flexibel, aber eben so, wie es die meisten brauchen.
PostgreSQL krankt, meiner Meinung nach, an seiner Komplexität und seinen Möglichkeiten, die von vielen gar nicht gebraucht werden.
Wenn eine andere Lösung einfacher zu nutzen ist, und die Funktionen bietet die man braucht, dann wird diese meistens auch genutzt.
Wie man so schön sagt: MySQL ist in 99% der Fälle einfach gut genug. Und einfach zu nutzen.
Wenn man aber, wie in meinem Fall, die speziellen Funktionen von Postges braucht, dann sieht die Sache natürlich anders aus. Dann ist MySQL eben nicht mehr gut genug, und fällt alleine wegen mangelnder Features aus der Auswahl raus.
Volle Zustimmung von mir.
Die Feature-Liste hört sich gut an!
Das einzige was ich mich frage, ist, was einen UNION DISTINCT von einem normalen UNION unterschiedet? Das ist doch der Normalfall - ansonsten gibts ja UNION ALL?
Übrigens halte ich das mit UNION für die schwerste Design-Fehlentscheidung von den "Machern" von SQL, hier den Weg anders rum als sonst zu gehen - falls das wer erklären kann, würde ich mich sehr freuen, das würde mich echt interessieren!