Login
Newsletter
Werbung

Thema: MySQL 8.0 freigegeben

9 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von UChef am Fr, 20. April 2018 um 17:01 #

Zu den Zeichensätzen gehört auch die Integration der Unicode-Daten von Version 9.0.0. Somit kann MySQL jetzt auch Emojis speichern.
Ich verstehe nicht, was eine DB-Engine dabei implementieren muss! Das Wort "Zeichensatz" wird in dem Artikel (und oftmals) leider mehrdeutig verwendet (neben dem eigentlichen Zeichensatz auch für "Encoding"), weswegen mir unklar ist, was eine Datenbank hier spezifisches mitbringen muss. Wenn ich intern ein Encoding verwende, welches den Unicode-Standard abbilden kann, was muss ich denn da anpassen? Ein Emoji ist aus Sicht des Encodings nur eine Sequenz von Code Units - inwiefern spielen dabei also neu definierte coded characters eine Rolle? Hat MySQL tatsächlich zuvor geprüft, ob ich eine Code Unit Sequenz speichere, die im Unicode-Standard noch nicht definiert ist? Letzteres wäre die einzig schlüssige Erklärung... und dann ist es imho fraglich, ob das Fluch oder Segen ist!

[
| Versenden | Drucken ]
  • 0
    Von ManInTheMiddle am Fr, 20. April 2018 um 17:43 #

    Es geht bei den Codepages meistens um die Sortierung.

    Also z.B. a...oöp...z und nicht a....zö

    [
    | Versenden | Drucken ]
    • 0
      Von UChef am Fr, 20. April 2018 um 17:49 #

      Das ist schon klar. Aber das wird ja in den collation regeln abgebildet. Im Artikel wird gesagt, dass ich erst jetzt zum Beispiel Emojis speichern kann. Wenn dem so wäre, müsste die DB ja explizit jeden coded character auf Zugehörigkeit zum jeweils aktuellen Zeichensatz hinter dem Encoding prüfen. Kapiere den Sinn dahinter nicht...

      [
      | Versenden | Drucken ]
    0
    Von ManInTheMiddle am Fr, 20. April 2018 um 17:48 #

    Außerdem gibt es verschiedene Möglichkeiten, manche Zeichen zu kodieren.

    Viele Umlaute kann man durch Zusammensetzung aus mehreren Symbolen oder durch den Code des Ergebnisses definieren

    Also z.B.:
    ö = ö
    ö = o + "

    [
    | Versenden | Drucken ]
    • 0
      Von UChef am Fr, 20. April 2018 um 17:52 #

      Der Inhalt kann der DB doch egal sein. Da kommt es ja nur drauf an, wie du die Daten reinpackst. Bei string Operationen könnte es da also maximal zu Problemen kommen... Ist das wirklich der einzige Grund, wieso man die Zeichen auf Bekanntheit prüft? (wenn dem überhaupt so ist)

      [
      | Versenden | Drucken ]
      • 0
        Von wochenende am Sa, 21. April 2018 um 14:09 #

        Der Inhalt kann der DB doch egal sein. Da kommt es ja nur drauf an, wie du die Daten reinpackst.

        Nein.

        Kleiner Überblick dazu:

        https://bit.ly/2F6khML
        https://bit.ly/2HlxUOs

        [
        | Versenden | Drucken ]
    0
    Von JonSnow am Sa, 21. April 2018 um 14:46 #

    Du hast dir die Frage eigentlich eh selbst beantwortet. Neue Code Units führen zu neuen Code Points. Die Datenbank muss diese kennen, wenn du String-Funktionen anwenden möchtest.
    Natürlich könntest du auch alles RAW speichern, hast dann aber entsprechende Einschränkungen bei der Abfrage.

    MySQL ist aber generell ein Murks .. da ist utf8 ja auch kein utf8 sondern ein nicht standardkonformes 3-Byte Encoding.

    [
    | Versenden | Drucken ]
    • 0
      Von UChef am So, 22. April 2018 um 15:30 #

      Du hast dir die Frage eigentlich eh selbst beantwortet. Neue Code Units führen zu neuen Code Points. Die Datenbank muss diese kennen, wenn du String-Funktionen anwenden möchtest.
      Ok, das stimmt. Wobei der Großteil an neuen Zeichen ja eigenständige Glyphen sind - zumindest wäre das mein Gefühl. Ergo kann die DB ja im Zweifel an den Stellen trennen, an denen sie eine Grenze zwischen Code-Points erkennt.

      Ist denn klar, wie die String-Operationen einer DB (bzw. hier speziell MySQL) arbeiten? Worauf operieren denn Split(), Right() usw.? Auf Code Points, Grapheme Clustern? Wie wird die Größe von String-Feldern festgelegt? Bezieht sich ein VARCHAR(10) auf 10 Code Points, arbeitet also Unicode basiert? Wenn ja, wäre es letztlich auch wieder egal, ob ich die Semantik hinter einem Code Point kenne oder nicht - wenn ich die ersten zwei Einheiten eines solchen Feldes haben möchte, dann sind das eben zwei Code Points. Anders sähe es mit anderen Einheiten aus; aber die wären mutmaßlich noch weniger gut zu verarbeiten ...

      MySQL ist aber generell ein Murks .. da ist utf8 ja auch kein utf8 sondern ein nicht standardkonformes 3-Byte Encoding.
      Ja, hab ich oben im ersten Kommetar ja auch schon angedeutet :x

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung