Ankündigung

Einklappen
Keine Ankündigung bisher.

MySQL - Latin1 oder UTF8?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MySQL - Latin1 oder UTF8?

    Ich lese immer wieder, dass man UTF8 nehmen soll, weil das besser ist. Gestern bin ich über einen Beitrag gestolpert, dass Latin1 weniger Platz brauchen würde und etwas performanter sei. Hab den Beitrag leider nicht gespeichert und finde ich jetzt nicht mehr. Wenn man sonnst so nach dem Thema googelt findet man eher Fragen und Anleitungen, wie man Latin1 zu UTF8 konvertiert. Meine geplante Anwendung soll nur in Deutschland laufen (ein Export in die weite Welt ist nicht vorgesehen ). Jetzt frage ich mich, ob ich Latin1 nehmen sollte oder trotzdem UTF8? Wenn ja, warum? Spiel es bei kleinen Anwendungen überhaupt irgend eine Rolle?
    PHP 8.3
    MariaDB 10.6
    Symfony 6.4 (LTS)

  • #2
    Mit UTF-8 bist du halt viel flexibler. Außerdem spart man sich unnötige Konvertierungen. Viele APIs und andere Software-Komponenten verwenden UTF-8. Warum sich also unnötig einschränken?

    Wenn du aus Platzgründen Latin1 nimmst, dann setzt du ziemlich komische Prioritäten. Wieviel Platzersparnis erhoffst du dir? 0,1%? 1%? Und kommts darauf wirklich an?

    Kommentar


    • #3
      Die Performance-Unterschiede wirst du vermutlich gar nicht bemerken. Witzigerweise hat MySQL früher versucht (ist das heute auch noch so? ), UTF-8 auch kleiner zu machen, um die Performance zu verbessern und nur 3 bytes pro Zeichen erlaubt - was nicht dem Standard entspricht und somit konntest du keine Emojis in der Datenbank speichern. Daher nehme ich immer utf8mb4_unicode_ci, so dies zur Auswahl steht - dort sind 4 bytes pro Zeichen erlaubt und somit ist dies Standardkonform. Zusätzlich bist du durch das unicode in der Lage, Internationale Sortierregeln anzuwenden.
      Tutorials zum Thema Technik:
      https://pilabor.com
      https://www.fynder.de

      Kommentar


      • #4
        OK, dann bleibe ich bei UTF-8. Für ein Projekt wo aber nur Zeichen eingesetzt werden ist utf8_general_ci richtig oder sollte ich auf utf8mb4_unicode_ci umsteigen?
        PHP 8.3
        MariaDB 10.6
        Symfony 6.4 (LTS)

        Kommentar


        • #5
          Zitat von Little Tester Beitrag anzeigen
          OK, dann bleibe ich bei UTF-8. Für ein Projekt wo aber nur Zeichen eingesetzt werden ist utf8_general_ci richtig oder sollte ich auf utf8mb4_unicode_ci umsteigen?
          Das ist die Collation, und nicht die Zeichenkodierung. Welche Collation für dich sinnvoll ist, musst du schon selber wissen. Das ist ja deine Entscheidung.

          Kommentar


          • #6
            Achso, ja. Also davon rede ich die ganze Zeit. In den HTML-Scripten benutze ich eh immer UTF-8. Mir geht es hier tatsächlich um das Feld in der Datenbank. Ich nehme aber an, dass die Aussagen von oben trotzdem ihre Gültigkeit behalten, dass man besser UTF8 einsetzt und nicht Latin1.

            Ich habe mir eben diesen Artikel durchgelesen. Darin steht, dass mittlerweile wohl utf8mb4_unicode_ci angesagt ist und nicht mehr utf8mb4_general_ci. utf8_general_ci wird gar nicht mehr erwähnt. Wie trifft man eigentlich solche Entscheidenden? Bei mir soll ja nur Text verarbeitet werden. Keine Smilies, keine Bilder, keine Dokumente. Letzteres vielleicht irgendwann mal, wenn das Projekt gut läuft so so genutzt wird, wie es angedacht ist.
            PHP 8.3
            MariaDB 10.6
            Symfony 6.4 (LTS)

            Kommentar


            • #7
              Welche Mysql Version hast du denn?

              Warum willst du die voreingestellte Kollation ändern?

              Es gibt einen Unterschied zwischen 5.7 und 8.X.
              Die Zeichenkodierung sollte auf alle Ebenen (Verbindung, DB, Tabelle) gleich sein. Heute nimmt man dazu utf8mb4. Die Sortierreihenfolge(collation) ist nur bei Namen interessant und sollte dann auch nur auf diese Spalte für die gebräuchliche Sprache geändert werden. Eine Änderung der Collation für die gesamte DB macht die Anwendung langsamer, da immer erst in der Übersetzungstabelle gesucht werden muss, das oft ja gar nicht notwendig ist(z.B. INT, DATE, etc.)

              https://dev.mysql.com/doc/refman/8.0...onnection.html

              Kommentar


              • #8
                - Ich bin bei IONOS und dort ist MySQL 5.7 momentan Stand der Dinge. Ich habe auch gerade nachgeguckt, ob beim Anlegen der DB eine andere Version angeboten wird. Ist nicht der Fall.

                - Voreingestellt ist bei Kollation gar nichts. Legt man eine neue Tabelle an und gibt da nichts an wird automatisch "utf8_general_ci" genommen. Früher war es glaub mal Latin1.

                - Die Frage, ob ichs ändern soll ergab sich, weil Andreas meinte, dass jetzt utf8mb4_unicode_ci aktuell ist.
                PHP 8.3
                MariaDB 10.6
                Symfony 6.4 (LTS)

                Kommentar


                • #9
                  Du sprichst und meinst Zeichenkodierung, ja die ist heute und auch bei deiner Version mit utf8mb4 gut gewählt. Das kannst mit charset einstellen. Du zeigst aber immer wieder die collation, auf Deutsch: alphabetische Sortierreihenfolge.

                  Der Unterschied soll mal aufgezeigt werden für Mysql Version 5.7
                  server_char_sets.png
                  charachter_set einfach erklärt:
                  _client, das ist unser PHP-Script zum Aufbau der Verbindung.
                  _connection, der Übertragungsweg. Beim Verbindungsaufbau als charset zu setzen.
                  _results, so wie die Daten zurückkommen, die wir abfragen
                  diese 3 Einstellungen müssen gleich sein, also hier utf8mb4, weil sonst gibt es Darstellungsprobleme mit den Nicht-ASCII-Zeichen, öäüß €, , etc.

                  _system ist die Zeichenkodierung unseres Betriebssystems, hier Linux. Ist UTF8 somit ok.
                  _filesystem ist binary, das soll uns nicht weiter interessieren, denn mit Dateisystem von Mysql kommen wir nicht in Berührung.
                  _server steht hier auf latin1, dies lässt sich auch nicht ohne weiteres ändern und auf den gemieteten Webhostern schon erst recht nicht. Das ist auch der Grund warum beim Erstellen einer Tabelle oder Datenbank die Zeichenkodierung angegeben werden muss, machen wir das nicht wird die DB in latin1 erstellt. Da wir oftmals auch nicht wissen, wie die Zeichenkodierung der Datenbank erstellt wurde, geben wir bei jeder Tabelle die Zeichenkodierung explizit vor, denn sonst würde sie von der DB und die DB vom Server übernehmen.

                  Mal eine Tabelle erstellt
                  PHP-Code:

                  CREATE TABLE 
                  `contacts` (
                    `
                  idint(11NOT NULL AUTO_INCREMENT,
                    `
                  first_namevarchar(50NOT NULL,
                    `
                  last_namevarchar(50COLLATE utf8mb4_german2_ci NOT NULL,
                    `
                  companyvarchar(80NOT NULL,
                    `
                  emailvarchar(255NOT NULL,
                    
                  PRIMARY KEY (`id`)
                  ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
                  • unterste Zeile default charset: dies ist die Zeichenkodierung, die für die ganze Tabelle gilt, also für alle neuen Spalten, egal wie die Zeichenkodierung in der DB lautet oder gar auf dem Server.
                  • 4. Zeile last_name: Die Zeichenkodierung gilt auch hier, wie für die ganze Tabelle angegeben, lediglich die Sortierreihenfolge ändern wir auf german2_ci. Das ci steht übrigens für case insensitive, das heisst, müller und Müller werden gleich behandelt. german2_ci sortiert so wie das mal im gelben Telefonbuch der Fall war(als es noch kein mobiles Telefonnetz gab). Siehe auch Wikipedia dazu.

                  Die Zeichensortierung folgt der Kodierung, daher hier utf8mb4_german2_ci. Das muss man sich raus suchen aus dem Handbuch oder man verlässt sich auf PHPMyadmin und Vergleichbare.

                  Alles gilt für Mysql Version 5.7.
                  Andere Versionen oder DBMS handhaben das unterschiedlich.

                  Kommentar

                  Lädt...
                  X