Statistik zur Verteilung der MySQL-Versionen

Es wird wieder einmal Zeit für die alljährlichen Zahlen (wie schon 2013 und 2012) zur Nutzung der bei uns angebotenen MySQL-Versionen.

Im Vergleich zum Vorjahr wurden insgesamt mehr Datenbanken angelegt, daher freut es uns umso mehr, dass auch die absolute Zahl der noch mit Version 3 und 4 betriebenen MySQL-DBs weiter abgenommen hat.

Mit Stand 28.05.2014 sind die bei uns erstellten MySQL-Datenbanken

  •   8% eine mit Version 3
  • 13% eine mit Version 4
  • 79% eine mit Version 5.5
Statistik MySQL-Versionen

MySQL-Versionen 2014

Somit ist die Nutzung der nicht mehr vom Hersteller unterstützten Versionen auf etwa ein Fünftel gefallen (21 Prozent).

Updatehinweise

Ein Update von MySQL 3 auf 4 ist im Kundenmenü und auch im ResellerProfessional mit wenigen Klicks möglich, lediglich in Ihren Skripten muss dann der Hostnamen für MySQL dann von mysql.ihredomain.endung auf mysql4.ihredomain.endung abgeändert werden.

Für ein Upgrade auf die Version 5.5 von MySQL ist etwas mehr Aufwand erforderlich. Nach einem manuellen Dump der Datenbankinhalte muss dieser anschließend in die neue Datenbank eingespielt werden, da sich viele Dinge im Datenbankformat selbst geändert haben, weshalb wir hierfür keine Automatisierung anbieten können.

Anleitungen und Tipps dazu finden Sie hier im Blog, in den FAQ, dem Forum und natürlich bei Fragen oder Problemen auch über unseren Kundenservervice.

End of article

Dietmar

Über den Autor

Dietmar

Dietmar ist seit 2005 bei domainFACTORY in wechselnden Aufgabenbereichen tätig. Seit 2013 unterstützt er als "Spezialist Qualitätssicherung Web" die Kollegen in der Entwicklungsabteilung bei allen Themen rund um Quality Assurance / Testing. Dabei kommt ihm die jahrelange Erfahrung im direkten und indirekten Kundensupport und der Begleitung bei der Einführung unseres ResellerProfessional-Systems zu Gute. Auch für viele Kollegen ist er bei Fragen dazu oder sehr alten Tarif-Konstellationen noch immer gerne eine Anlaufstelle.

10 Kommentare

Die von Ihnen hier erhobenen Daten werden von der domainfactory GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.df.eu/datenschutz


  • ad1601com
    ad1601com - 3. Juni 2014 um 14:14 Uhr

    Na, dann gehe ich doch mal mit zumindest prozentual gutem Beispiel voran:

    MySQL 3: 0%
    MySQL 4: 7%
    MySQL 5: 93%

  • Anonymous
    Anonymous - 3. Juni 2014 um 19:24 Uhr

    MySQL ist eine richtige Plage. Mir ist schleierhaft warum _AUSSCHLIESSLICH_ dieses Ungetüm bei dF im sharedHosting eingesetzt wird.

    Bin jetzt auf eine jiffyBox umgestiegen und dort glücklich mit einem ordentlichen DBMS. (In meinem konkreten Fall PostgreSQL)

  • epos_jk
    epos_jk - 4. Juni 2014 um 15:39 Uhr

    Also – bei mir ist die einzige Datenbank mit Mysql 3 diejenige, die von ResellerProfessional zu Beginn angelegt wurde und wahrscheinlich nicht mehr verwendet wird – was ist das empfohlene Vorgehen damit? (die einzige Datenbank, die das Namensformat dbnnnnnn hat – die anderen heißen alle dbnnnnnn_n bzw dbnnnnnn_nn)

  • Dietmar
    Dietmar - 4. Juni 2014 um 16:06 Uhr

    Hallo ad1601com,
    sehr schön und die 7% sind bis zu den nächsten Statistiken dann noch geschafft 😉

  • Dietmar
    Dietmar - 4. Juni 2014 um 16:14 Uhr

    Hallo Anonymous,
    MySQL ist im SharedHosting-Bereich sehr weit verbreitet, wird von vielen OpenSource-Applikationen unterstützt und ist für Anfänger für das Verständnis von relationalen Datenbanken einfacher zu erlernen. PostgreSQL ist zwar auch mit vielen Anwendungen nutzbar und spielt seine Vorteile gerade bei sehr großen Datenbanken aus, allerdings ist die Syntax für weniger versierte Anwender aufgrund der Abweichungen von den meisten SQL-Database-Engines teilweise unvorteilhafter.

    Alle unsere Kunden mit einem ManagedServer können PostgreSQL auch darauf installieren und nutzen oder – wie sie – auf einer JiffyBox mit allen Freiheiten einrichten.

  • Dietmar
    Dietmar - 4. Juni 2014 um 16:15 Uhr

    Hallo epos_jk,
    Sie können die RP1-Datenbank löschen, sofern Sie für Ihre Kunden NICHT das RP-Migrate verwenden. Sollte dies noch der Fall sein, wird die Datenbank des RP1 in Teilen leider noch verwendet.

  • Anonymous
    Anonymous - 4. Juni 2014 um 23:18 Uhr

    @Dietmar:

    Könnten Sie bitte erläutern was genau Sie mit:

    „allerdings ist die Syntax für weniger versierte Anwender aufgrund der Abweichungen von den meisten SQL-Database-Engines teilweise unvorteilhafter. “

    meinen?

    Das Standard-SQL ist doch in allen relationalen Datenbanksystem absolut ident. PgSQL ist sicher nicht schwieriger zu lernen als Oracle und MySQL ist sicher weniger standardkonform als PostgreSQL.

    Dass es weit verbreitet ist, ändert nichts daran, dass es ein grausames Stück Software ist. Leider hat sich im Laufe der Zeit nicht immer das Beste durchgesetzt (das ist sogar sehr selten der Fall)

  • Anonymous
    Anonymous - 4. Juni 2014 um 23:21 Uhr

    Beispiel: ein VARCHAR-Feld anlegen, dass NOT NULL ist und dann einfügen.

    INSERT INTO mein_feld VALUES(“); und staunen. MySQL verhält sich hier alles andere als logisch (der Standard spezifiziert das Verhalten meines Wissens nach nicht vollständig) und fügt einen LEEREN STRING ein. Der „logische“ Sinn von „NOT NULL“ wäre jedoch gewesen, dass dies nicht geschieht. (Damit ist „NOT NULL“ bei VARCHAR völlig sinnlos) Andere Datenbanken verhalten sich wie logisch zu erwarten wäre.

    (Auch wenn Strenggenommen das Leerwort nicht die leere Menge ist – Theoretische Informatik ahoi! :))

  • Tommes
    Tommes - 9. Juni 2014 um 12:30 Uhr

    „Leerer String“ ist nicht gleich „NULL“!

  • Anonymous
    Anonymous - 10. Juni 2014 um 12:02 Uhr

    @Tommes: Wie ich am Ende schrieb, ist dem nicht so, nein.

    Nur was bringt mir „NOT NULL“ bei einem VARCHAR dann?

    JEDE andere Datenbank die wir im Einsatz haben, verhält sich wie erwartet und wirft bei einem leeren String die Exception, dass der Inhalt nicht null sein darf.

    Dass das Leerwort nicht gleich die leere Menge ist, ist bei einem VARCHAR mit NOT NULL einfach Bullshit.

    Ist total sinnvoll, wenn man dann im Code NUR FÜR MYSQL (!!!) überall dort wo so etwas passieren könnte einen extra Check einbauen darf, damit nicht doch ein leerer String eingefügt wird.

    Seitdem wir vollends auf PostgreSQL umgestiegen sind, passt auch die Performance wieder. Mit selber Hardware und selbem Datenumfang.

    MySQL ist eine grauenhafte Plage. MariaDB ginge ja noch einigermaßen, wobei auch da der Großteil der grauenhaften Codebasis mit übernommen wurde.

    Na ja, für mich heißt das einfach, dass ich niemandem mehr einen normalen Hoster empfehlen kann, wenn ich das Zeug dann warten muss. Für MySQL und andere Verbrechen an der Menschheit ist meine Lebenszeit nämlich zu kurz.