Irgendwie erschließt sich mir der Sinn nicht...

[AlexNofftz]

Irgendwie erschließt sich mir der Sinn dieser Maßnahme nicht. DB2 ist doch schon ein voll ausgereiftes DBMS, das sehr viel mehr als MySQL unterstützt. Wo man bei MySQL noch an Details von SQL99 knabbert und Dinge wie Transaktionen und Fremdschlüssel nur über den InnoDB-Umweg unterstützt, ist in DB2 schon eine ganze Reihe von SQL2003 drin.

Falls ich also die DB2-Features benötige, kann ich doch viel einfacher direkt DB2 verwenden, anstatt diesen Umweg zu nehmen. Will ich ein schlankes und schnelles System haben, bleibe ich eben bei MySQL.

Der einzige Grund, der mir hier einfällt wäre, dass eine bestehende Software sehr viel von MySQLs eigener Syntax anstelle von offiziellem SQL verwendet und somit nicht portierbar ist, aber das ist denke ich eher ein Problem der Programmierung und nicht des DBMS...

Bis dann,
Alex

[Putzlappen]

AlexNofftz schrieb:
-------------------------------------------------------
> Irgendwie erschließt sich mir der Sinn dieser
> Maßnahme nicht. DB2 ist doch schon ein voll
> ausgereiftes DBMS, das sehr viel mehr als MySQL
> unterstützt. Wo man bei MySQL noch an Details von
> SQL99 knabbert und Dinge wie Transaktionen und
> Fremdschlüssel nur über den InnoDB-Umweg
> unterstützt, ist in DB2 schon eine ganze Reihe von
> SQL2003 drin.

MySQL ab 5.0 unterstützt übrigens auch SQL 2003. Davon mal ganz abgesehen ist InnoDB kein Umweg, sondern eine ganz reguläre Option. Während andere DBMS dem Anwender halt sagen: "Friss oder stirb", kann man bei MySQL die bewußte Entscheidung zwischen Transaktionssicherheit und roher Performance treffen.

Ich empfehle dazu folgende Lektüre:
http://blog.koehntopp.de/archives/1349-Leben-mit-Fehlern-der-Schluessel-zum-Scaleout.html

> Falls ich also die DB2-Features benötige, kann ich
> doch viel einfacher direkt DB2 verwenden, anstatt
> diesen Umweg zu nehmen. Will ich ein schlankes und
> schnelles System haben, bleibe ich eben bei
> MySQL.

Nochmal, InnoDB ist kein Umweg. Ob DB2 als Storage Engine einer sein wird, wird die konkrete Implementation zeigen. DB2 als Storage Engine für MySQL zu wählen ist sicher interessant, wenn ich ohnehin schon DB2 laufen habe und meine MySQL-Anwendungen zentralisiert in der gleichen Datenbank verwalten möchte (keine Sonderlocken für Backups usw.) und/oder ich auf dem Server nur einen schlanken zusätzlichen Serverprozess haben möchte, der lediglich das SQL entgegennimmt und die Resultsets von DB2 durchreicht, anstatt eine komplett eigene Datenbank mit dem dazugehörigen zusätzlichen Ressourcenverbrauch parallel zu installieren.

> Der einzige Grund, der mir hier einfällt wäre,
> dass eine bestehende Software sehr viel von MySQLs
> eigener Syntax anstelle von offiziellem SQL
> verwendet und somit nicht portierbar ist, aber das
> ist denke ich eher ein Problem der Programmierung
> und nicht des DBMS...

Nur kann es dem Kunden ja völlig egal sein, woran es im Endeffekt liegt - der will nur, daß es läuft.

[Void]

Putzlappen schrieb:
-------------------------------------------------------
> AlexNofftz schrieb:
> --------------------------------------------------
> MySQL ab 5.0 unterstützt übrigens auch SQL 2003.

Ein kleines Subset von SQL 2003, keine einzige mir bekannte DB unterstützt es komplett, und die Anzahl der unterstützen Features ist bei MySQL eher noch erbärmlich klein.

> Davon mal ganz abgesehen ist InnoDB kein Umweg,
> sondern eine ganz reguläre Option. Während andere
> DBMS dem Anwender halt sagen: "Friss oder stirb",
> kann man bei MySQL die bewußte Entscheidung
> zwischen Transaktionssicherheit und roher
> Performance treffen.

Unsinn. Im professionellen Datenbank Bereich kommen 80% der Performance von einem guten Queryplanner, und der ist bei MySQL derzeit noch sehr dürftig. Klar, solche Sachen wie "select x from y where z" performieren super mit MyISAM, aber Queries dieser Art sind dort eher selten. Im Webbereich stimmt dein Einwand natürlich, die Abfragen die üblicherweise dort anzutreffen sind, sind eher trivial.

Ich hab erst vor einigen Monaten eine MySQL Anwendung migrieren müssen weil der Planner so lausig ist, und das war ein Join von grade mal 5 Tabellen. Mag sein dass man bei der MySQL-Version noch was machen könnte, interessanterweise konnten sowohl Oracle als auch Postgresql die gleiche Abfrage ohne jegliche Optimierungen oder Tricks um den Faktor 1000 schneller ausführen. Ok, Faktor 1000 ist falsch, MySQL 92 Sekunden, PostgreSQL 13 Millisekunden, möge sich jeder selbst ausrechnen wieviel das ist.

> Nur kann es dem Kunden ja völlig egal sein, woran
> es im Endeffekt liegt - der will nur, daß es
> läuft.

Nein, sollte es eigentlich nicht wenn ihm seine Daten was Wert sind. Ist aber leider so - es ist dem Kunden egal bis er damit gegen die Wand fährt.

[Markus42]

AlexNofftz schrieb:
-------------------------------------------------------
> Irgendwie erschließt sich mir der Sinn dieser
> Maßnahme nicht. DB2 ist doch schon ein voll
> ausgereiftes DBMS, das sehr viel mehr als MySQL
> unterstützt.

MySQL ist halt gerade "in".

Wobei es wohl drei verschiedene Version von DB2 zu geben scheint (DB2 für i5/OS, z/OS und Linux/Unix/Windows). Ich habe keine Ahnung, wie verschieden die sind und warum es hier nur um i5/OS geht.

Markus

[Hermann L.]

> Unsinn. Im professionellen Datenbank Bereich
> kommen 80% der Performance von einem guten
> Queryplanner, und der ist bei MySQL derzeit noch
> sehr dürftig. Klar, solche Sachen wie "select x
> from y where z" performieren super mit MyISAM,
> aber Queries dieser Art sind dort eher selten. Im
> Webbereich stimmt dein Einwand natürlich, die
> Abfragen die üblicherweise dort anzutreffen sind,
> sind eher trivial.

Vermutlich arbeitest Du mit veralteten Versionen. Wir setzen MySQL im Datawarehouse Bereich ein, und haben bei komplexeren Joins genau gegenteilige Erfahrung gesammelt: PostgreSQL konnte MySQL das Wasser nicht reichen und fiel damit aus dem Rennen.

Und ich denke, dass dies nicht ein Einzelfall ist. SAP beispielsweise, hat als weitere Datenbank, die mit R/3 zusammenarbeitet MySQL, nicht aber PostgreSQL gewählt.

Was natürlich nicht heissen soll, das PostgreSQL besser oder schlechter ist. Beide sind OpenSource, und der Anwender hat das Glück sich frei entscheiden zu können.

[Termigrator]

Markus42 schrieb:
-------------------------------------------------------
> AlexNofftz schrieb:
> --------------------------------------------------
> -----
>> Irgendwie erschließt sich mir der Sinn dieser
>> Maßnahme nicht. DB2 ist doch schon ein voll
>> ausgereiftes DBMS, das sehr viel mehr als MySQL
>> unterstützt.
>
> MySQL ist halt gerade "in".

Und so kann man alte Datenbestände aus DB/2 mit neuen Mysql-Applikationen mischen und ggf. migrieren.