MySQL verliert RDBMS Backend

[tjp]

Demnächst unterstützt MySQL kein BDB RDBMS Backend mehr. Damit gibt es nur noch ein transaktionsfähiges RDBMS-Backend (InnoDB) für MySQL. Allerdings ist die Zukunft von InnoDB ungewies, da der Hersteller desselben von Oracle aufgekauft wurde. Näheres siehe Original Heise Meldung

 

[derJan]

Finde ich persönlich nicht schade. Es war ja schon seit längerem so, dass bdb (jedenfalls unter Debian) nicht benutzt wurde (skip-bdb in my.cnf), da MySQL schon angekündigt hatte den bdb Support einzustellen. Was war eingentlich der Vorteil von bdb?

Jan

 

[tjp]

BDB ist ein stabilieres Format als InnoDB, d.h. man kann es nach einem Crash mit größeren Wahrscheinlichkeit wiederherstellen und die Transaktionen laufen besser durch. InnoDB hat da zum Teil seine Probleme. Die anderen Tabellentypen sind zwar schön, aber ein richtiges DBMS muß nun einmal ein RDBMS sein und das ist bei den anderen Tabellentypen nicht erfüllt. Die große Frage wird sein, wie lange es noch InnoDB geben wird, weil InnoBase ebenfalls von Oracle geschluckt worden ist.

Wenn es das ebenfalls nicht mehr gibt, ist MySQL für kritische Anwendungen gestorben.

 

[derJan]

Okay danke für die Erklärung. Wie sieht es denn mit PostgreSQL aus? Ist zwar nicht so verbreitet und bekannt wie MySQL, soll aber eine sehr gutes RDBMS sein. Soweit ich das auch sehe, darf man MySQL nur im Open-Source Umfeld "gratis" einsetzen. Bei PostgreSQL ist das ja anders, oder?

Jan

 

[tjp]

Wie sieht es denn mit PostgreSQL aus?

Da gibt es keine Probleme, da das Projekt von keinen externen DBMS Backends abhängig ist, und es hat die sehr viel freizügigere BDS Lizenz. Kommerzielle Projekte auf Basis von PostgreSQL sind kein Problem, selbst kommerzielle Ableger von PostgreSQL sind möglich.

Das leistungsfähigere RDBMS war und ist PostgreSQL in Relation zu MySQL auch.

 

[slayercon]

Das leistungsfähigere RDBMS war und ist PostgreSQL in Relation zu MySQL auch.

Leistungsfähig im Sinne von Transaktionssicherheit oder von Abfrage und IO Performance da hört man nämlich andere Dinge von PostgreSQL....

Transaktionen in MyISAM und MySQL löse ich mit den AOP Ansatz von Spring und Hibernate da spielt die DB dann eine untergeordnete Rolle.

Und für die Datenbank sage ich :Hauptsache schnell ....

 

[tjp]

Leistungsfähig im Sinne von Transaktionssicherheit oder von Abfrage und IO Performance da hört man nämlich andere Dinge von PostgreSQL....

PostgreSQL ist meist schneller als MySQL und schafft das ganze auch noch transaktionssicher. Der Tabellentyp Heap von MySQL ist natürlich schneller, einige ganz simple Dinge können mit MyISAM Tabelle schneller sein, aber das meiste ist gleich auf, bzw. PostgreSQL ist deutlich schneller, wenn die SQL Abfragen komplexer werden.

MyISAM ist für die meisten Anwendungen unbrauchbar, da man keine relationalen Datensätze haben kann. Ich habe schon genug kaputte Datensätze in Datenbanken gesehen, so daß eine nicht relationale Tabelle ein absolutes "no go" ist.

Wenn ich bei vergleichbarer Performance das ganze auch relational inklusive Contraints haben kann nehme ich lieber das RDBMS, was mir mehr Sicherheit bietet. Trigger, Stored Procedures und all die Sachen sind wirklich Gold wert, wenn man einmal Fehler der Applikation in der DB debuggen mußte.