Aktuelle Gegenüberstellung von MySQL und Postgres

Servus zusammen,

bisher habe ich alle meine Projekte mit MySQL gelöst und MySQL hat ja auch mittlerweile einiges zu bieten. Auch die Tools (MySQL Administrator und MySQL Query Browser) laufen bei mir 1A und ich habe noch keine Tools für PG gefunden, die hier mithalten können.


Allerdings habe ich nun den ersten Fall, in dem MySQL nicht das bietet, was ich benötige (s. anderer Beitrag von mir: Unteranfragen in PG).

Bevor ich noch weitere Überraschungen erlebe, wollte ich die Funktionalität von MySQL und die von Postgres mal gegenüberstellen. Wenn ich Google bemühe finde ich aber nur Vergleiche, die schon sehr alt sind und früher war MySQL wirklich nicht zu gebrauchen (überhaupt keine Unteranfragen etc.). Mittlerweile sieht es ja doch etwas anders aus.

Könnt Ihr mir vielleicht eine Quelle nennen, in der beide Systeme gegenübergestellt werden?

Oder wieso nutzt Ihr PG? Gibt es Funktionen, die Euch aufgefallen sind, die in PG vorhanden sind, in MySQL aber nicht?

Wie sieht es umgekehrt aus? Wenn ich nun auf PG migriere möchte ich ja nicht, dass mir nach 2 Wochen auffällt, dass meine bisherigen Anwendungen Probleme machen :slight_smile:

Gruß

Mike

Ich brauche mir nur anzuschauen, was EXPLAIN unter MySQL liefert, um zu sehen, daß es Schrott ist.

Allerdings habe ich nun den ersten Fall, in dem MySQL nicht das bietet, was ich benötige (s. anderer Beitrag von mir: Unteranfragen in PG).

Willkommen.

Bevor ich noch weitere Überraschungen erlebe, wollte ich die Funktionalität von MySQL und die von Postgres mal gegenüberstellen. Wenn ich Google bemühe finde ich aber nur Vergleiche, die schon sehr alt sind und früher war MySQL wirklich nicht zu gebrauchen (überhaupt keine Unteranfragen etc.). Mittlerweile sieht es ja doch etwas anders aus.

Könnt Ihr mir vielleicht eine Quelle nennen, in der beide Systeme gegenübergestellt werden?

Warum sollte man täglich aufs neue beweisen, wie Scheiße MySQL ist? Wird langweilig auf Dauer. Ansonsten findest Du a bissl was auf meinen Del.Icio.Us - Seiten.


Oder wieso nutzt Ihr PG? Gibt es Funktionen, die Euch aufgefallen sind, die in PG vorhanden sind, in MySQL aber nicht?

Jede Menge. Unter andere intelligentere Abfragepläne bei komplexen Abfragen, hilfreiche Funktionen wie generate_series() und die absolute Fokussierung auf Datenintegrität.

Wie sieht es umgekehrt aus? Wenn ich nun auf PG migriere möchte ich ja nicht, dass mir nach 2 Wochen auffällt, dass meine bisherigen Anwendungen Probleme machen > :slight_smile:

Wie jetzt, Du hast doch Probleme mit MySQL, oder?


Andreas

Generell nehmen sich beide Datenbanken nicht viel, jedenfalls nach aussen hin. Wenn man genauer hinschaut, stellt man fest, das sich PostgreSQL viel mehr auf Datensicherheit, Datenintegrität(!) und Einhaltung der Standards konzentriert. Das hat auch ein paar Nachteile, speziell, wenn man Code für Mysql entwickelt hat und dann diesen portieren muss. Wenn man von Anfang an auf PG entwickelt, ist das weniger problematisch.

Ein paar Hinweise darauf kannst du in einem Vortrag von mir finden:
Writings Andreas ‘ads’ Scherbaum

An Tools empfehle ich dir sowohl PgAdminIII als grafische Oberfläche wie auch PHPPgAdmin als webbasierte Oberfläche.

Eine persönliche Erfahrung noch: ich habe auch (irgendwann im letzten Jahrtausend) mit Mysql angefangen. Damals war das noch 3.23 und ich kannte nichts anderes. Als uns das erste Projekt mit einigen Tausend Datensätzen um die Ohren geflogen ist, habe ich mir gedacht: “Das kann es doch eigentlich nicht sein, das ist eine Datenbank, aber so verhalten tut sie sich nicht”.
Daraufhin habe ich mich umgeschaut, die Alternativen begutachtet und bin bei PG hängengeblieben. Das war zu Anfang eine Umstellung, aber ich habe sie nie bereut. Die Webseite hatte ich dann von Mysql auf PG umgestellt, konnte ungefähr 2/3 des PHP-Codes herauswerfen, der sich um Würgarounds kümmerte (brauchte es nicht mehr, die DB hat sich um Datensicherheit gekümmert), musste mich aber auch um Performancefragen kümmern. Sicherheit ist nie mit Schnelligkeit zu erkaufen.

Einspruch:

PG galt lange Zeilt als lahmer als MySQL. Wenn man aber erstens eine aktuelle MySQL-Version mit InnoDB verwendet (um zumindest ansatzweise was vergleichbares bzgl. RI und so weiter zu haben) und zweitens eine aktuelle Version von PG und drittens eine hinreicht komplexe Abfrage auf ausreichend viele Daten hat, dann hat sich PG nicht mehr hinter MySQL zu verstecken. Wie ich schon sagte: intelligente(re) Abfragepläne, z.B. mit Ausnutzung mehrerer Indexe pro abgefragter Tabelle und Bitmap-Index-Scan, was PG kann und MySQL nicht, zeigen dann doch recht schnell das Ende des Mythos: MySQL sei schneller…

Andreas

Wo siehst du da einen Einspruch?

Solange Mysql schnell sein soll, ist es schnell (MyIsam).
Sobald es sicher sein soll (InnoDB), gibt man Schnelligkeit dafür her.

Stimmt doch alles :wink:

Hi,

erstmal danke für Eure Antworten.

Wie jetzt, Du hast doch Probleme mit MySQL, oder?

Ja, das schon. Aber wenn sich herausstellen würde, dass in MySQL ein Teil nicht geht und in PG auch nicht muss ich ja für beides Workarounds schaffen, dann ist es auch egal :slight_smile:

Was sind denn “intelligente Abfragepläne”?

In PG sind sicherlich einige Dinge anders, muss mich damit erst noch genauer auseinandersetzen. PgAdmin III sieht sehr nett aus.

Meistens ist für mich die Geschwindigkeit wichtig, aber Fremdschlüssel wären schon mal ne feine Sache gewesen und das hat mit MyISAM ja doch nicht so super geklappt :wink:

Gruß

Mike

Nimm einen (komplizierten) Query in Mysql und in Postgresql, setze ein EXPLAIN (oder bei PG auch ein EXPLAIN ANALYZE und/oder VERBOSE davor) und betrachte dir mal die Ausgaben. Die Unterschiede sollten deutlich sein.
Generell schafft der Planer bei PG auch bessere Resultate, weil er wesentlich mehr Daten (zum Host, zur Umgebung, zur Datenbasis und was nicht alles) einbeziehen kann.


Meistens ist für mich die Geschwindigkeit wichtig, aber Fremdschlüssel wären schon mal ne feine Sache gewesen und das hat mit MyISAM ja doch nicht so super geklappt

Nun, bei Mysql hast du ja die Wahl, entweder Geschwindigkeit (Myisam) oder Fremdschlüssel (Innodb), beides geht nicht … obwohl mir da letztens ein Replikation-Setup für empfohlen wurde Grusel

Nun, wenn du nur Geschwindigkeit willst, ganz ehrlich, bleib bei Mysql. Das toppt keine andere Datenbank. Ansonsten, wenn du auf InnoDB wechselst: da kann PostgreSQL entweder mithalten oder besser sein.

Wenn Du Dir mal ein EXPLAIN ANALYSE von PG anschaust, dann siehst Du, das der Planner kostenbasiert arbeitet. Jede mögliche Aktion wird vorher bewertet, wie ‘teuer’ sie vermutlich wird (Plattenzugriffe, CPU-Last, …), beim EXPLAIN ANALYSE sieht man die Schätzung und die tatsächlichen Kosten. (manchmal wichtig zum Tuning)
Außerdem kann PG pro SELECT und table mehr als nur einen Index gleichzeitig nutzen, was MySQL wohl noch nicht kann (In-memory Bitmap Index Scan). Bei sehr komplexen Abfragen kommen dann auch im Vergleich zu MySQL oftmals bessere Abfragestrategien raus. (der Planner stellt u.U. auch mal Abfragen logisch um, wenn es vom Resultat her gleich aber schneller ist)

Das EXPLAIN von MySQL ist im Vergleich dazu, ähm, ach schau selbst.

In PG sind sicherlich einige Dinge anders, muss mich damit erst noch genauer auseinandersetzen. PgAdmin III sieht sehr nett aus.

Wobei PGAdmin ein externes Tool ist und an sich nix mit PG zu tun hat. Würde es ein gleichwertiges Tool für MySQL gäben, wäre MySQL deswegen noch lange nicht gleichwertig.

Meistens ist für mich die Geschwindigkeit wichtig, aber Fremdschlüssel wären schon mal ne feine Sache gewesen und das hat mit MyISAM ja doch nicht so super geklappt > :wink:

MySQL und referentielle Integrität, das ist, naja. Zu früheren Zeiten, als MySQL es gar nicht konnte (noch kein InnoDB), wurde RI ganz offen sogar als unnützer Kram abgetan.

MySQL Reference Manual for version 3.23.37.

Eigentlich hätte man MySQL dafür zumachen sollen…


Andreas

Ok, danke für die Infos. Ich werds mir mal genauer anschauen. Ich benötige einfach eine View mit Unteranfragen, weiß nicht, wie ich mein Problem sonst lösen soll. Ich kann die Logik höchstens aus der Datenbank ziehen und in die Anwendung packen, aber das ist ja absoluter Quatsch :slight_smile:

Da glaubt man, man hat nun alles zusammen und kann nun endlich anfangen die Anwendung zu entwickeln und bei 9x% rollt einem die Software Steine in den Weg :slight_smile: )

Gruß

Mike

Ach da fällt mir noch ein: Muss ich Benutzer eigentlich über createuser einrichten oder geht das auch über Queries? Ich habe da eine Tabelle gefunden, wo Benutzeraccounts drinstehen. Ist es genug, wenn ich hier einen Eintrag hinzufüge oder fehlt dann irgendwas wesentliches?

Solange Du Deine Probleme in unverständliche Rätsel packst, wird Dir keiner helfen können. Zeig doch einfach ein Beispiel.

Ach da fällt mir noch ein: Muss ich Benutzer eigentlich über createuser einrichten oder geht das auch über Queries?

Die Lösung ist simpel, sie besteht aus einem Leerzeichen. Und zwar zwischen create und user.

Andreas

Hallo Mike,

du sollstest dir die Doku http://www.postgresql.org/files/documentation/pdf/8.2/postgresql-8.2-A4.pdf herunter laden und Dir das Kapitel “I. SQL Commands” anschauen. Bei Deinen Vorkenntnissen ist es für Dich wesentlich hilfreicher, wenn du dir den Syntax der SQL-Befehle anschaust. Dann kannst Du auch die Leistungsfähigkeit der Datenbank besser beurteilen. U. a. ist da auch der SQL-Befehl “CREATE USER” beschrieben.

Als ehemaliger Anwender von MySQL kann ich Dir nur PostgreSQL empfehlen. Ich will es mal allgemein ausdrücken: Wo ich früher mit MySQL Klimmzüge machen musste, gestaltet sich das heute mit PostgreSQL wesentlich einfacher und übersichtlicher.


mfg

fristo

Converted the site from MySQL to PostgreSQL | jamonation.com

Man beachte (in den Kommentaren), der Typ hat unter MySQL MyISAM benutzt. Mehr Argumente braucht man wohl nicht.

Andreas

Hi,

danke, werde das Kapitel lesen. Also ich hatte folgendes Problem, wo ich mit MySQL hängengeblieben bin:

Ich habe 3 Tabellen. Eine zeigt den aktuellen Lagerbestand:

Artikel | Anzahl

Und zwei Tabellen, Input und Output. Nun möchte ich hieraus den neuen Lagerbestand berechnen, also als View darstellen.

Im Grunde in der Form:

Lagerbestand + Input - Output. Meine Idee mal grob:

Lagerbestand (Artikel, Anzahl) union Input (Artikel, Anzahl) union Output (Artikel, -Anzahl), das ganze dann einfach nach Artikel gruppiert und aufsummiert.


Eine Alternative war das ganze mit einem Full outer Join zu verknüpfen, aber den gibts in MySQL ja auch nicht. Da hätte ich dann irgendwas mit left outer und right outer und dann noch except oder sonst was bauen müssen.

Also im Grunde sieht meine View (jetzt mal grad freihand) so aus:

create view ‘lagerbestand_aktuell’ as
select artikel, sum(anzahl) from (
select artikel, anzahl from lagerbestand union
select artikel, anzahl from input union
select artikel, anzahl * (-1) from output
) group by artikel;

Und hier ist bei MySQL das Problem, dass im From-Teil bei Views keine Unteranfragen sein dürfen.

Gruß

Mike

Schon mal schlecht. Du hast Artikel. Diese haben erst einmal keinen Bestand, aber andere Stammdaten. Und dann eine Bewegungstabelle. Den Bestand in der Stammdatentabelle des Artikels zu halten ist schon mal schlecht.

Und zwei Tabellen, Input und Output. Nun möchte ich hieraus den neuen Lagerbestand berechnen, also als View darstellen.

Input und Output sind dann identisch, unterschiedlich ist nur das Vorzeichen. Also kann man das zusammenfassen, ob Zu- oder Abgang regelt ein Bool-Feld.

Mach 2 Tabellen, Artikel mit id und Name sowie Bewegung mit id, Zu- oder Abgang und Anzahl.

Dann ist das einfach:

test=*# select * from artikel;
 id | name
----+------
  1 | a1
  2 | a2
(2 rows)

Time: 0.898 ms
test=*# select * from bewegung;
 id | zu | anzahl
----+----+--------
  1 | t  |     10
  1 | f  |      5
  2 | t  |     20
  2 | t  |     15
  2 | f  |     25
(5 rows)

Time: 0.917 ms
test=*# \d bestand
     View "public.bestand"
 Column  |  Type   | Modifiers
---------+---------+-----------
 id      | integer |
 name    | text    |
 bestand | bigint  |
View definition:
 SELECT a.id, a.name, sum(
        CASE
            WHEN b.zu THEN b.anzahl
            ELSE - b.anzahl
        END) AS bestand
   FROM artikel a
   LEFT JOIN bewegung b USING (id)
  GROUP BY a.id, a.name;

test=*# select * from bestand ;
 id | name | bestand
----+------+---------
  2 | a2   |      10
  1 | a1   |       5
(2 rows)

Andreas

Hi,

danke für die Antwort.

Schon mal schlecht. Du hast Artikel. Diese haben erst einmal keinen Bestand, aber andere Stammdaten. Und dann eine Bewegungstabelle. Den Bestand in der Stammdatentabelle des Artikels zu halten ist schon mal schlecht.

Also mit Artikel meinte ich eigentlich die Artikelnummer, sorry. Die Artikelnummer verwende ich als ID. Diese Stammdatentabelle existiert in der Form noch nicht, es geht im Moment wirklich nur um Ein- und Ausgänge. Daher kann ich keinen anderen Wert als ID verwenden, weil ich so eine Tabelle nicht habe :slight_smile: Ich will nur speichern, was da war, was rein und rausging und demzufolge nun da sein müsste.

Beides in eine Tabelle zu packen hatte ich mir damals auch überlegt, aber ich dachte damals, dass es übersichtlicher sei, wenn ich für beides zwei getrennte Tabellen habe. Das System läuft bereits, wird jetzt eben noch erweitert. Die Tabelle “bewegung” lässt sich mittels eines unions aber ja auch einfach aus meinen beiden Tabellen als View nachbauen.


Sehr interessant finde ich Deine Query mit dem CASE. So hätte ich das nun definitiv nicht gemacht, sehr nice :slight_smile:

Gruß

Mike

IMHO nicht wirklich. Zu- oder Abgang, beides hat Gründe, Timestamp, Anzahl, …

Sehr interessant finde ich Deine Query mit dem CASE. So hätte ich das nun definitiv nicht gemacht, sehr nice > :slight_smile:

Ja, CASE ist geil…


Andreas

Jo find ich auch eine nette Sache. Trotzdem mal ne Frage interessehalber: Warum nicht das Vorzeichen bei der Anzahl mitspeichern, als positv für Zugang und negativ für Abgang? Gibts dafür einen Grund (ausser das es zu einfach wäre :wink: )?

Gruß Uwe

Nein, wäre lediglich zu einfach…

Andreas

Hallo!

PostgreSQL hat im Vergleich zu anderen Systemen sicher viele Stärken:

  • Liberale Lizenz zu sehr günstigen Kosten :slight_smile:
  • Viele viele positive technische Eigenschaften
  • Brauchbare Doku

Negativ aufgefallen ist mir bis jetzt nur die String-Sortierung.
Siehe diesen Thread:
http://www.pg-forum.de/allgemeines/1130-unerwuenschte-sortierung.html
Ich vermute, das ist immer noch so aktuell. Habe jetzt nicht getestet.
D. h. es kann eigentlich gar keine Strings sortieren und delegiert an das Betriebssystem.
Ich finde, die Designer von PG sollten eine konkrete Vorstellung davon haben, wie eine Sortierung zu sein hat und das dann auch implementieren.

Beste Grüße
Lenno

Nein, die Sortierung wird geregelt beim Erstellen der DB. Es nutzt dazu den LC_COLLATE - Mechanismus, das kann auch unterschiedlich zum OS sein. Und nein, warum sollten die Designer von PG das Rad zum Xten Male erfinden, und nein, warum sollten sie eine fixe und für alle zwangshaft geltende Sortierung vorschreiben?

Andreas