Wäre es nicht gut, erst einmal die existierende Codebase in Ordnung zu bringen? Ich erinnere mich an einen Post eines Entwicklers über den desaströsen Zustand bei den letzten MySQL-Releases. Seit Monaten (oder bald Jahren) nicht gefixte kritische Bugs, die viele betreffen, angekündigte Features nicht so richtig (als experimentell gekennzeichnet und unfertig) implementiert, etc. Wieso haben sie InnoDB verkaufen lassen?
Warum nicht neue Konzepte probieren, vielleicht festellen, das sie besser sind, und alte fallen lassen, statt sinnlos zu versuchen alte Konzepte zu flicken. Das ist aus meiner Sicht gar keine schlechte Sache, sofern man alte Datenbanken migriert bekommt. Nebenbei: ich glaube es war 5.1, was so stark in der Kritik war.
Das ganze Konzept dieser verschiedenen Engines ist doch sowieso bescheuert. Jede kann irgendwas was die andere nicht kann. D.h. wenn ich einen vermeindlichen Vorteil von Engine A habe, dann erkaufe ich mir das wiederum durch irgendwelche anderen fehlenden Features. Und es ist ja nicht so, dass man unbedingt mehrere Engines braucht um alle benötigten Featuren unter einen Hut zu bringen. Siehe pgSql, mssql, db2 und natürlich oracle.
"Jede kann irgendwas was die andere nicht kann. D.h. wenn ich einen vermeindlichen Vorteil von Engine A habe, dann erkaufe ich mir das wiederum durch irgendwelche anderen fehlenden Features."
Das ist zwar richtig, setzt aber vorraus das du wirklich alles in einer Tabelle willst. Was viele vergessen: Man kann in MySQL problemlos alle Engines in einer DB nutzen.
Wichtige Tabellen nutzen dann InnoDB, die Suchtabellen nutzen MyISAM, temp/session Tabellen Memorytables usw.
DAS ist ja der Vorteil von MySQL. Durch die verschiedenen Engines kann man das beste jeder Lösung nutzen.
"Siehe pgSql"
Die lange weder ordentliche/überhaupt Volltextsuche noch Replikation hatten.
... bis du mal beides brauchst: Performance UND Transaktionen; dann schaut es schlecht aus ...
Mal ehrlich: Die Fälle in denen ein Entwickler nicht einen Rollback braucht, wenn was schief geht, sind doch wirklich selten. Sind wirklich soo viele mit Krattler-Programmen (meist in PHP) zufrieden, bei dem die Sicherung von letzter Nacht (so vorhanden und lauffähig) bei irgend welchen (Benutzer- Datenaustausch, XYZ-) Fehlern eingespielt werden muss??
".. bis du mal beides brauchst: Performance UND Transaktionen; dann schaut es schlecht aus ..."
InnoDB und co. sind ja nicht langsam, nur MyISAM ist schneller. Aber eben auch schneller als alle anderen DBs mit Features wie Transaktionen. MyISAM ist fix weil es wenig kann. Aber InnoDB und co. sind deswegen nicht langsam im Vergleich zu anderen.
"Sind wirklich soo viele mit Krattler-Programmen (meist in PHP) zufrieden, bei dem die Sicherung von letzter Nacht (so vorhanden und lauffähig) bei irgend welchen (Benutzer- Datenaustausch, XYZ-) Fehlern eingespielt werden muss??"
Eindeutig ja. Sieht man ja. Warum auch nicht, für viele Aufgaben ist es eben auch absolut ausreichend.
"Das ist zwar richtig, setzt aber vorraus das du wirklich alles in einer Tabelle willst." Was ist daran so ungewöhnlich das ich in einer Tabelle Volltextsuche, Fremtschlüssel und Transaktionsfähigkeit brauche. Von Geometrischen Typen oder Geodaten mal ganz zu schweigen...
"Was ist daran so ungewöhnlich das ich in einer Tabelle Volltextsuche, Fremtschlüssel und Transaktionsfähigkeit brauche. Von Geometrischen Typen oder Geodaten mal ganz zu schweigen..."
Wenn du das alles willst solltest du aber vielleicht auch mal über dein DB Design nachdenken anstatt auf die DB rumzuhacken
Und wenn MySQL deine Anforderungen nicht erfüllt, glaubst du das interessiert jemanden? Nimm halt PostgreSQL, Firebird oder Ingres. Es gibt mehr als genug Alternativen. Aber für User die ohne solche Mixe auskommen ist MySQL sehr gut geeignet, wenn auch sicher nicht die einzige sinnvolle Wahl.
Es ist am Ende nur eine DB, eine unter vielen. Aber sie ist nicht deswegen schlecht weil sie nicht für jeden optimal ist.
Was bei einer DB zählt sind doch Zuverlässigkeit und Geschwindigkeit. Hat zufällig wer eine Übersicht über die diesbezügliche Qualität dieser (aller?) Engines? PBXT hat Version 1.0 und XtraDB "build 10" (offenbar ist der build schon 10 mal durchgelaufen ) Aber was heißt das schon ... also wenn da wer ne gute aktuelle Übersicht hat: Bitte her damit
Noch ne Frage: Warum gibts eigentlich nicht postgres als engine für MySQL? Würd alle diesbezgl. Streitereien beenden.
Aus gewissem Abstand betrachtet, scheint es um MySQL seit Jahren ziemliches Chaos zu geben und die Zukunfts scheint auch ungeklärt. Hat MySQL eigentlich irgendeinen Vorteil gegenüber Postgresql?
Auf Transaktionen kann man, wenn man ernsthaft mit Datenbanken arbeitet natürlich nicht verzichten. Features wie Replikation (slony1) möchte ich auch nicht missen.
Ist MySQL sooo viel schneller, oder gibts sonst nen Vorteil?
Vapourware ist anscheinend beliebt bei Freetards. Warten wir ab was von Sun kommt. Bisher hist MySQL einfach lächerlich. Entweder Transaktionen oder ein schnelles "select count(*) from mytable" ist einfach ein Unding
Nur die Lizenz BSD vs. GPL. In allem anderen kann ich nicht wiedersprechen. Eine Typische Geschichte zu MySQL ist übrigens die Mono-/Net-Anbindung. Wo ich das gelesen habe, habe ich nur mit dem Kopfgeschüttelt.
...Auf Transaktionen kann man, wenn man ernsthaft mit Datenbanken arbeitet natürlich nicht verzichten. ...
Mich würde interessieren, was das bedeutet. Ich arbeite ernsthaft mit einem Kunden an einer Lösung, die ihm nutzt. Und bei vielen würden Transaktionen mehr schaden als nutzen. Die Daten liegen auch in einer 'Datenbank' (nicht relational). Die Transaktionen sind mittlerweile zur einer Monstranz der IT geworden - es geht richtig um Glaube.
> Die Transaktionen sind mittlerweile zur einer Monstranz der IT geworden - es geht richtig um Glaube.
Es geht nicht um Glaube sondern Integrität. Davon ab sind atomare Aktionen (je nach Abstraktionsschicht) auch nicht zu verachten. Klar, man muß es nicht brauchen. Nur wenn doch stehst du ohne doof da.
Die Transaktionen sind mittlerweile zur einer Monstranz der IT geworden - es geht richtig um Glaube
Bei manchen ja!
Aber: Wenn mehrere voneinnander abhängige Queries z.B. bei NestedSet-Operationen benötigt werdn sind Transaktion mit Rollback-Möglichkeit einfach nur geil. Klar kann man die Tabelle locken, aber was passiert, wenn aus einem 5er Query-Set nach 3 mal UPDATES das darauf folgende SELECT fehlschlägt?
Es gilt wie für jede Technologie: Sinnvoll Einsetzen!
Von Patrick Willam am Di, 23. Dezember 2008 um 10:44 #
> Ist MySQL sooo viel schneller, oder gibts sonst nen Vorteil?
Der Witz dabei ist ja, daß MySQL nicht schneller, sondern langsamer als PostgreSQL ist. (Sofern man transaktionslose Engines außen vor läßt; aber dann kann man ja nicht ernsthaft von einem RDBMS reden und stattdessen gleich zu SQLite greifen.)
Diese "urban legend", daß MySQL ja sooo viel schneller ist, stammt aus Vergleichen von Kühen mit Waschmaschinen. Sobald man einigermaßen adäquat Äpfel mit Birnen vergleicht, also die verschiedenen RDBMS mit den gleichen Aufgaben in gleichen Anwendungsfällen, dann ist selbst eine standardmäßig ungetunte PostgreSQL so gut wie immer mindestens so schnell wie eine standardmäßig getunte MySQL+InnoDB.
Was dir PostgreSQL sonst noch bietet: o logischer, klarer und dadurch einfacher o größere Konformität zum SQL-Standard als die meisten anderen RDBMS o Man muß sich für gute Leistung nicht um Interna des RDBMS kümmern, sondern kann sich auf seine Lösung konzentrieren. o Zur Replikation muß keine Tabelle zu keiner Zeit in einen Read-Only-Modus gesetzt werden.
Von vielen Benutzer/-innen wird PostgreSQL daher geradezu als "freundlich" angesehen bzw. wahrgenommen.
"(Sofern man transaktionslose Engines außen vor läßt; aber dann kann man ja nicht ernsthaft von einem RDBMS reden und stattdessen gleich zu SQLite greifen.)"
Das ist Unsinn. Es gibt viele Situationen in der man auf Transaktionen problemlos verzeichten kann, und in denen die reine Antwortszeit um ein vielfaches wichtiger ist. Nur weil du das nicht nutzt heisst es nicht das es nie so ist. Und MySQL ist eben doch etwas ganz anderes als SQLite, obwohl das auch nett ist, aber eben nicht in der selben Liga spielt.
"Zur Replikation"
Dafür war Replikation langezeit nicht direkt verfügbar, die externen Lösungen sub-optimal (soweit meine Erfahrung).
"logischer, klarer und dadurch einfacher"
Hier würde ich gerne wissen was du damit genau meinst. MySQL ist eine ziemlich einfach strukturierte Software, die zudem wenige Abhängigkeiten nach außen hat. Welche Punkte empfindest du als unklar?
Postgre ist schon nett, keine Frage, aber in der Vergangenheit, und da wurde vieles entschieden, war sie eher langsam (ich denke da nur an die Connect-Zeiten die man teils in Sekunden messen konnte... aber auch die Engine selbst war nicht optimiert wie heute).
MySQL hat einfach einige klare stärken: 1. Sehr simpel aufgebaut 2. Sehr offen konstruiert (austauschbare und mixbare engines) 3. Potential für eine hohe Geschwindigkeit ohne Transaktionen (die nunmal nicht jeder braucht). 4. Sehr gute Anbindung der meisten Sprachen
Nicht jeder mag die für sich benötigen, aber hey dann nimmt man eben z.B. Firebird, Postegre oder was auch immer.
Was meinst du? Die Konfiguration oder den Code? Letzteres interessiert den Unser nicht. Ersteres kann ich nicht bestätigen.
"2. Sehr offen konstruiert (austauschbare und mixbare engines)"
Sehr /offen konstruiert/ Argument. Bei PostgreSQL sind die "Batterien schon dabei", - will sagen - Bei PostgreSQL brauche ich mir über so was noch nicht mal Gedanken machen.
"3. Potential für eine hohe Geschwindigkeit ohne Transaktionen (die nunmal nicht jeder braucht). "
Ich wage mal die Behauptung: sqlite ist in 95% der Fälle die bessere Wahl, weil _NOCH_SCHNELLER_!!!!1111eins-eins-eins
"4. Sehr gute Anbindung der meisten Sprachen"
Nenne mir 5 Sprachen, die bei sf.net mehr als 100 Projekte hat, und die keine Anbindung an PostgreSQL hat, aber eine für MySQL.
Was du nicht ganz verstehen scheinst, wie wohl einige Hardcore-Fans eines Projektes: Eine Stärke eines Projektes muss nicht die Schwäche eines anderen sein. Postgre kann durchaus stärken von MySQL teilen, oder andere haben.
Aber: "Bei PostgreSQL sind die "Batterien schon dabei" -> Das ist unsinn. PostgreSQL mangelte es sehr lange an Volltextsuche und eingebauter Replikation. Hier war MySQL deutlich schneller. Aus der heutigen sicht ist "wer-war-zuerst-da" natürlich unwichtig, aber bei der Frage "Warum-MySQL?" war es das lange nicht. Vor allem bei der Frage "Warum kann nicht jede engines alles" bei MySQL hatte auch PostgreSQL hier lange keine völlig zufriedenstellende Antwort.
MySQL ist einfach mit vielen wesentlichen Funktionen schneller gewesen (Hohe Geschwindigkeit, gute Anbindung an Scriptsprachen, Replikation, Volltextsuche), während PostgreSQL aus einer völlig anderen richtung kam, in dem ein schneller Erfolg deutlich schwerer zu erreichen war. Heute ist die Situation wie sie ist, also MySQL als größte Open Source DB, und die beiden haben sich deutlich angehähert. Postgre ist fixer geworden, mySQL Funktionsreicher.
Wobei ich eh nicht sehe warum so viele Postgre User immer so auf MySQL rumhacken. Nutzt es nicht wenn ihr es nicht mögt, keiner zwingt euch.
Antworten wie "Ich wage mal die Behauptung: sqlite ist in 95% der Fälle die bessere Wahl, weil _NOCH_SCHNELLER_!!!!1111eins-eins-eins" zeugen nicht unbedingt von einem echten willen eine andere DB zu akzeptieren, die immerhin als einer der Schlüsselkomponenten Open Source in Unternehmen trägt.
...wenn mysql mal eine funktionierende Default-Speicher-Engine implementieren würde. Es nervt, wenn man sich zwischen kaputten Transaktionen und nicht funktionierenden Volltext-Indices entscheiden muß.
Darüber hinaus würde ich vorschlagen, daß man mal die anderen Hausaufgaben macht und die ganzen unsinnigen Gotchas beseitigt, vom Datumshandling bis zu Nested Queries, Triggern und komplexen Constraints. Und ein gescheiter Query Optimizer könnte auch nicht schaden.
Von Kritisch... am Di, 30. Dezember 2008 um 17:16 #
Ich habe lange auf MySQl und anderen DB's gearbeitet.... MySQL ist ok solange es nicht um unternehmnskritische Dinge oder um DB's geht die 24/7 sehr rassig Antworten müssen. MySQL ist ok aber ich nerve mich auch schon seit Jahren dass es einfach niemmand schafft von diesen Jungs mal eine Engine ganz ausreifen zu lassen.
Ich erinnere mich an einen Post eines Entwicklers über den desaströsen Zustand bei den letzten MySQL-Releases. Seit Monaten (oder bald Jahren) nicht gefixte kritische Bugs, die viele betreffen, angekündigte Features nicht so richtig (als experimentell gekennzeichnet und unfertig) implementiert, etc.
Wieso haben sie InnoDB verkaufen lassen?
Dim
Das ist zwar richtig, setzt aber vorraus das du wirklich alles in einer Tabelle willst.
Was viele vergessen: Man kann in MySQL problemlos alle Engines in einer DB nutzen.
Wichtige Tabellen nutzen dann InnoDB, die Suchtabellen nutzen MyISAM, temp/session Tabellen Memorytables usw.
DAS ist ja der Vorteil von MySQL. Durch die verschiedenen Engines kann man das beste jeder Lösung nutzen.
"Siehe pgSql"
Die lange weder ordentliche/überhaupt Volltextsuche noch Replikation hatten.
Mal ehrlich: Die Fälle in denen ein Entwickler nicht einen Rollback braucht, wenn was schief geht, sind doch wirklich selten.
Sind wirklich soo viele mit Krattler-Programmen (meist in PHP) zufrieden, bei dem die Sicherung von letzter Nacht (so vorhanden und lauffähig) bei irgend welchen (Benutzer- Datenaustausch, XYZ-) Fehlern eingespielt werden muss??
InnoDB und co. sind ja nicht langsam, nur MyISAM ist schneller. Aber eben auch schneller als alle anderen DBs mit Features wie Transaktionen.
MyISAM ist fix weil es wenig kann. Aber InnoDB und co. sind deswegen nicht langsam im Vergleich zu anderen.
"Sind wirklich soo viele mit Krattler-Programmen (meist in PHP) zufrieden, bei dem die Sicherung von letzter Nacht (so vorhanden und lauffähig) bei irgend welchen (Benutzer- Datenaustausch, XYZ-) Fehlern eingespielt werden muss??"
Eindeutig ja. Sieht man ja. Warum auch nicht, für viele Aufgaben ist es eben auch absolut ausreichend.
Was ist daran so ungewöhnlich das ich in einer Tabelle Volltextsuche, Fremtschlüssel und Transaktionsfähigkeit brauche. Von Geometrischen Typen oder Geodaten mal ganz zu schweigen...
Wenn du das alles willst solltest du aber vielleicht auch mal über dein DB Design nachdenken anstatt auf die DB rumzuhacken
Und wenn MySQL deine Anforderungen nicht erfüllt, glaubst du das interessiert jemanden? Nimm halt PostgreSQL, Firebird oder Ingres. Es gibt mehr als genug Alternativen.
Aber für User die ohne solche Mixe auskommen ist MySQL sehr gut geeignet, wenn auch sicher nicht die einzige sinnvolle Wahl.
Es ist am Ende nur eine DB, eine unter vielen. Aber sie ist nicht deswegen schlecht weil sie nicht für jeden optimal ist.
Hat zufällig wer eine Übersicht über die diesbezügliche Qualität dieser (aller?) Engines?
PBXT hat Version 1.0 und XtraDB "build 10" (offenbar ist der build schon 10 mal durchgelaufen
Aber was heißt das schon ... also wenn da wer ne gute aktuelle Übersicht hat: Bitte her damit
Noch ne Frage: Warum gibts eigentlich nicht postgres als engine für MySQL?
Würd alle diesbezgl. Streitereien beenden.
Engine | InnoDB | MyISAM | Kickfire | PBXT | Brighthouse | Cluster | Federated | Memory | Archive | Merge | Falcon | Maria | XtraDB | CSV | Blackhole
Transakt. | Ja | Nein | ? | Ja | ? | ? | ? | Nein | Nein | Nein | Ja | Nein | Ja | Nein | Ja
Zuverläss. | ++ | ++ | ...
Lesegeschw. | +/- | ++ | ...
Schreibge. | -- | ++ | ...
Aus gewissem Abstand betrachtet, scheint es um MySQL seit Jahren ziemliches Chaos zu geben und die Zukunfts scheint auch ungeklärt.
Hat MySQL eigentlich irgendeinen Vorteil gegenüber Postgresql?
Auf Transaktionen kann man, wenn man ernsthaft mit Datenbanken arbeitet natürlich nicht verzichten. Features wie Replikation (slony1) möchte ich auch nicht missen.
Ist MySQL sooo viel schneller, oder gibts sonst nen Vorteil?
Grüsse
Sebastian
Warten wir ab was von Sun kommt. Bisher hist MySQL einfach lächerlich. Entweder Transaktionen oder ein schnelles "select count(*) from mytable" ist einfach ein Unding
In allem anderen kann ich nicht wiedersprechen.
Eine Typische Geschichte zu MySQL ist übrigens die Mono-/Net-Anbindung. Wo ich das gelesen habe, habe ich nur mit dem Kopfgeschüttelt.
Mich würde interessieren, was das bedeutet. Ich arbeite ernsthaft mit einem Kunden an einer Lösung, die ihm nutzt. Und bei vielen würden Transaktionen mehr schaden als nutzen. Die Daten liegen auch in einer 'Datenbank' (nicht relational). Die Transaktionen sind mittlerweile zur einer Monstranz der IT geworden - es geht richtig um Glaube.
Es geht nicht um Glaube sondern Integrität. Davon ab sind atomare Aktionen (je nach Abstraktionsschicht) auch nicht zu verachten.
Klar, man muß es nicht brauchen. Nur wenn doch stehst du ohne doof da.
Bei manchen ja!
Aber:
Wenn mehrere voneinnander abhängige Queries z.B. bei NestedSet-Operationen benötigt werdn sind Transaktion mit Rollback-Möglichkeit einfach nur geil. Klar kann man die Tabelle locken, aber was passiert, wenn aus einem 5er Query-Set nach 3 mal UPDATES das darauf folgende SELECT fehlschlägt?
Es gilt wie für jede Technologie: Sinnvoll Einsetzen!
gruss
A.
Der Witz dabei ist ja, daß MySQL nicht schneller, sondern langsamer als PostgreSQL ist.
(Sofern man transaktionslose Engines außen vor läßt; aber dann kann man ja nicht ernsthaft von einem RDBMS reden und stattdessen gleich zu SQLite greifen.)
Diese "urban legend", daß MySQL ja sooo viel schneller ist, stammt aus Vergleichen von Kühen mit Waschmaschinen. Sobald man einigermaßen adäquat Äpfel mit Birnen vergleicht, also die verschiedenen RDBMS mit den gleichen Aufgaben in gleichen Anwendungsfällen, dann ist selbst eine standardmäßig ungetunte PostgreSQL so gut wie immer mindestens so schnell wie eine standardmäßig getunte MySQL+InnoDB.
Was dir PostgreSQL sonst noch bietet:
o logischer, klarer und dadurch einfacher
o größere Konformität zum SQL-Standard als die meisten anderen RDBMS
o Man muß sich für gute Leistung nicht um Interna des RDBMS kümmern, sondern kann sich auf seine Lösung konzentrieren.
o Zur Replikation muß keine Tabelle zu keiner Zeit in einen Read-Only-Modus gesetzt werden.
Von vielen Benutzer/-innen wird PostgreSQL daher geradezu als "freundlich" angesehen bzw. wahrgenommen.
Beste und weihnachtliche Grüße!
Das ist Unsinn. Es gibt viele Situationen in der man auf Transaktionen problemlos verzeichten kann, und in denen die reine Antwortszeit um ein vielfaches wichtiger ist.
Nur weil du das nicht nutzt heisst es nicht das es nie so ist. Und MySQL ist eben doch etwas ganz anderes als SQLite, obwohl das auch nett ist, aber eben nicht in der selben Liga spielt.
"Zur Replikation"
Dafür war Replikation langezeit nicht direkt verfügbar, die externen Lösungen sub-optimal (soweit meine Erfahrung).
"logischer, klarer und dadurch einfacher"
Hier würde ich gerne wissen was du damit genau meinst. MySQL ist eine ziemlich einfach strukturierte Software, die zudem wenige Abhängigkeiten nach außen hat. Welche Punkte empfindest du als unklar?
Postgre ist schon nett, keine Frage, aber in der Vergangenheit, und da wurde vieles entschieden, war sie eher langsam (ich denke da nur an die Connect-Zeiten die man teils in Sekunden messen konnte... aber auch die Engine selbst war nicht optimiert wie heute).
MySQL hat einfach einige klare stärken:
1. Sehr simpel aufgebaut
2. Sehr offen konstruiert (austauschbare und mixbare engines)
3. Potential für eine hohe Geschwindigkeit ohne Transaktionen (die nunmal nicht jeder braucht).
4. Sehr gute Anbindung der meisten Sprachen
Nicht jeder mag die für sich benötigen, aber hey dann nimmt man eben z.B. Firebird, Postegre oder was auch immer.
Was meinst du? Die Konfiguration oder den Code? Letzteres interessiert den Unser nicht. Ersteres kann ich nicht bestätigen.
"2. Sehr offen konstruiert (austauschbare und mixbare engines)"
Sehr /offen konstruiert/ Argument. Bei PostgreSQL sind die "Batterien schon dabei", - will sagen - Bei PostgreSQL brauche ich mir über so was noch nicht mal Gedanken machen.
"3. Potential für eine hohe Geschwindigkeit ohne Transaktionen (die nunmal nicht jeder braucht). "
Ich wage mal die Behauptung: sqlite ist in 95% der Fälle die bessere Wahl, weil _NOCH_SCHNELLER_!!!!1111eins-eins-eins
"4. Sehr gute Anbindung der meisten Sprachen"
Nenne mir 5 Sprachen, die bei sf.net mehr als 100 Projekte hat, und die keine Anbindung an PostgreSQL hat, aber eine für MySQL.
Eine Stärke eines Projektes muss nicht die Schwäche eines anderen sein. Postgre kann durchaus stärken von MySQL teilen, oder andere haben.
Aber: "Bei PostgreSQL sind die "Batterien schon dabei" -> Das ist unsinn. PostgreSQL mangelte es sehr lange an Volltextsuche und eingebauter Replikation. Hier war MySQL deutlich schneller.
Aus der heutigen sicht ist "wer-war-zuerst-da" natürlich unwichtig, aber bei der Frage "Warum-MySQL?" war es das lange nicht.
Vor allem bei der Frage "Warum kann nicht jede engines alles" bei MySQL hatte auch PostgreSQL hier lange keine völlig zufriedenstellende Antwort.
MySQL ist einfach mit vielen wesentlichen Funktionen schneller gewesen (Hohe Geschwindigkeit, gute Anbindung an Scriptsprachen, Replikation, Volltextsuche), während PostgreSQL aus einer völlig anderen richtung kam, in dem ein schneller Erfolg deutlich schwerer zu erreichen war.
Heute ist die Situation wie sie ist, also MySQL als größte Open Source DB, und die beiden haben sich deutlich angehähert. Postgre ist fixer geworden, mySQL Funktionsreicher.
Wobei ich eh nicht sehe warum so viele Postgre User immer so auf MySQL rumhacken. Nutzt es nicht wenn ihr es nicht mögt, keiner zwingt euch.
Antworten wie "Ich wage mal die Behauptung: sqlite ist in 95% der Fälle die bessere Wahl, weil _NOCH_SCHNELLER_!!!!1111eins-eins-eins" zeugen nicht unbedingt von einem echten willen eine andere DB zu akzeptieren, die immerhin als einer der Schlüsselkomponenten Open Source in Unternehmen trägt.
Darüber hinaus würde ich vorschlagen, daß man mal die anderen Hausaufgaben macht und die ganzen unsinnigen Gotchas beseitigt, vom Datumshandling bis zu Nested Queries, Triggern und komplexen Constraints. Und ein gescheiter Query Optimizer könnte auch nicht schaden.
MySQL ist ok aber ich nerve mich auch schon seit Jahren dass es einfach niemmand schafft von diesen Jungs mal eine Engine ganz ausreifen zu lassen.