utf8mb4_unicode_520_nopad_ci vs. utf8mb4_unicode_520_ci – Vor- und Nachteile von "NOPAD"-Kollationen

  • SQL

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    utf8mb4_unicode_520_nopad_ci vs. utf8mb4_unicode_520_ci – Vor- und Nachteile von "NOPAD"-Kollationen

    Ich habe eine MariaDB-Datenbank mit der Kollation "utf8mb4_unicode_520_nopad_ci" angelegt. Ich hätte auch "utf8mb4_unicode_520_ci", also ohne "_nopad" nehmen können. Mein Gedanke war: wenn der User "unnötige" Leerzeichen eintragen will, dann soll er die Möglichkeit haben.

    Mittlerweile bin ich von der Idee aber nicht mehr so ganz überzeugt. Zum einen dachte ich, es geht auch um führende Leerzeichen, aber es geht nur um nachfolgende (und die sind seltener sinnvoll als führende). Und es verursacht mehr Probleme als es Vorteile bietet (zumindest soweit ich das im Moment überblicke). Ohne die NOPAD-Kollation werden aber, wie ich gesehen habe, nachfolgende Leerzeichen trotzdem in der DB gespeichert, also es ist leider kein automatisches Trimmen.

    Nun die Frage(n):

    1.) Welche Fälle würden euch einfallen, in welchen NOPAD-Kollationen sinnvoll sind?
    2.) Gibt es Vor- und Nachteile von NOPAD-Kollationen, insbesondere was die Performance angeht?

    Die Frage zielt auch darauf ab, dass ein Umstellen der Kollation einer Datenbank nicht mit einem simplen Befehl möglich ist (man muss Datenbank, alle Tabellen und alle Felder umstellen (ja, es geht mit phpMyAdmin recht simpel)) und es könnte Probleme mit UNIQUE-Spalten geben, welche mal mit und mal ohne nachfolgende Leerzeichen befüllt wurden (aber sonst mit demselben Begriff). Also bevor ich umständlich und mit Risiko umstelle wäre die Frage, ob NOPAD evtl. doch irgendwo einen Vorteil für mich bietet.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Hi @Marcus Gräfe ,

    standardmäßig ist es ja so, dass bei einem string compare mit = die trailing spaces ignoriert werden, im Gegensatz zu LIKE.
    Als Beispiel enthält eine Tabelle im Feld name "peter " mit einem Leerzeichen am Ende. Ein WHERE `name` = 'peter' würde diesen Datensatz finden, ein WHERE `name` LIKE 'peter' nicht - kommt mir ohnehin widernatürlich vor, aber das ist das Standardverhalten.

    Ausführliches Beispiel:

    SQL-Abfrage

    1. -- utf8mb4_0900_bin mit PAD_ATTRIBUTE -> NO PAD
    2. -- utf8mb4_unicode_ci mit PAD_ATTRIBUTE -> PAD SPACE
    3. create table if not exists users (id integer, name varchar(100) COLLATE 'utf8mb4_unicode_ci', name2 varchar(100) COLLATE 'utf8mb4_0900_bin');
    4. truncate table users;
    5. insert into users (id, name, name2) values (1, 'peter', 'peter');
    6. insert into users (id, name, name2) values (2, 'peter ', 'peter ');
    8. -- PAD SPACE
    9. select * from users where `name` = 'peter'; -- Findet #1 und #2
    10. select * from users where `name` = 'peter '; -- Findet #1 und #2
    11. select * from users where `name` LIKE 'peter'; -- Findet #1
    12. select * from users where `name` LIKE 'peter '; -- Findet #2
    14. -- NO PAD
    15. select * from users where `name2` = 'peter'; -- Findet #1
    16. select * from users where `name2` = 'peter '; -- Findet #2
    17. select * from users where `name2` LIKE 'peter'; -- Findet #1
    18. select * from users where `name2` LIKE 'peter '; -- Findet #2


    Kann man auch direkt online ausprobieren: extendsclass.com/mysql/d38cf7d (man muss das select statement das ausgegeben werden soll, vorher mit der Maus markieren, ranzig aber wenn man's weiß geht's schon)

    Zur Frage:
    1) finde ich generell sinnvoller und intuitiver als das Standardverhalten mit PADSPACE. Ich will nicht dass "peter" gefunden wird wenn ich nach "peter " suche und umgekehrt, vor allem bei einer condition mit =, man muss also auf LIKE umsteigen für einen ordentlichen Stringvergleich obwohl das signifikant langsamer ist.
    2) zur Performance kann ich nix sagen, müsste man benchmarken, hab auch auf die Schnelle keine sinnvollen Beiträge dazu im Internet finden können.
    Hello World

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Link“ ()

    Danke für die Antwort. Ich werde bei Gelegenheit mal einen Benchmark machen.

    Einen echten Vorteil von NOPAD kann ich noch nicht erkennen, sofern man bedenkt, dass nachfolgende Leerzeichen oft unbeabsichtigt, z. B. bei Copy-&-Paste-Aktionen, entstehen. Aber immerhin habe ich nun eine Pro-Stimme dazu gehört.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    @Marcus Gräfe ja also man kriegt halt mehr Ergebnisse und das SQL Statement ist kürzer wenn man mit Daten arbeitet, bei denen man keine Lust oder es vergessen hatte, sie zu validieren bevor sie in die Datenbank geschrieben wurden. Vor allem will ich aber bei einer Prüfung von Strings mit = auf Gleichheit (!) keine implizit vorgenommenen Manipulationen. Wenn ich das will, kann ich Funktionen wie LIKE, LOWER oder TRIM etc immer noch mit in meine Abfrage nehmen, genau dann suche ich aber ja auch nicht nach einer exakten Zeichenfolge. Und ob ein Leerzeichen dort versehentlich drin ist oder nicht, eine Datenbank hat keine Emotionen und sollte auch nix ungefragt "ausbessern" - vielleicht ist das auch ne Spur zu pragmatisch gedacht, aber ich hab's gern straightforward. Andersrum betrachten es sicher viele (ich denke so wie du auch) eher als Komfort bzw Feature, kann ich nachvollziehen, allerdings ist das ein Setting, das nicht optional ist. Einmal für diesen Weg entschieden kann man nicht zurück, also nicht programmatisch. Vermutlich ist es dieser Umstand der mir aufstößt.

    Hier würde mich tatsächlich eine Umfrage reizen um zu sehen, wie das Thema betreffend die Präferenzen verteilt sind, wirklich ganz interessant :) Beim Thema Case-Sensitivity zum Beispiel gehen die Meinungen ja auch weit auseinander, wobei ich's hier verstehen kann, es gibt für beide Varianten gleichermaßen einen Haufen Argumente für und gegen.
    Hello World

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „Link“ ()

    Link schrieb:

    Vor allem will ich aber bei einer Prüfung von Strings mit = auf Gleichheit (!) keine implizit vorgenommenen Manipulationen.

    Genau das war auch mein Gedanke, warum ich mich ursprünglich für NOPAD entschieden habe.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

Facebook
Telefonspende