Bonjour
Auriez vous un tuto ou cours clair sur l'interclassement en SQL ?
J'ai trouvé des choses évidemment sur le web mais ce n'est pas toujours clair... Ou alors je sature et j'ai besoin de parler à qqun :)
J'utilise phomyadmin
Merci
Version imprimable
Bonjour
Auriez vous un tuto ou cours clair sur l'interclassement en SQL ?
J'ai trouvé des choses évidemment sur le web mais ce n'est pas toujours clair... Ou alors je sature et j'ai besoin de parler à qqun :)
J'utilise phomyadmin
Merci
Hello
T'as pas du chercher beaucoup... Ce n'est pourtant pas une notion complexe... ;)
Tu as des tutos a foison sur YT notamment :
https://youtu.be/1Bj1GnPXNxo
Bonne recherche
Il y a un article de SQLPro sur les collations (ou interclassements) ICI
Ok merci je vais aller voir ça...
Salut à tous.
La seule question que tu dois te poser est celle de la langue que tu vas utiliser.
Si, comme je le suppose, tu vas utiliser le français et pourquoi pas l'anglais, tu dois utiliser LATIN1 et LATIN1_GENERAL_CI.
Si au contraire, tu vas utiliser le chinois, l'arabe ou une langue utilisant un alphabet particulier, il faut trouver le bon jeu de caractères.
Il en existe un qui répond à ce problème, qui est UTF8MB4 et UTF8MB4_GENERAl_CI.
En dehors de cela, tu peux vouloir faire la distinction entre les minuscules ou les majuscules, voire de trier dans un ordre particulier.
Alors oui, il existe d'autres collation qui peuvent répondre à cette attente. Je ne pense pas que ton besoin est de cet ordre là.
Il faut savoir que l'UTF8MB4 utilise de 1 à 4 octets pour stocker 1 caractère, ce qui peut provoquer inutilement des problèmes dans la longueur des chaînes de caractères, ce que tu n'auras pas avec le LATIN1 puisque 1 caractère = 1 octet.
Cordialement.
Artemus24.
@+
Sûrement pas. Il faut utiliser utf8mb4 et utf8mb4_0900_ai_ci, les paramètres par défaut de MySQL.Citation:
Si, comme je le suppose, tu vas utiliser le français et pourquoi pas l'anglais, tu dois utiliser LATIN1 et LATIN1_GENERAL_CI.
Cela permet de gérer (presque) tout type de caractères sans problèmes. Utiliser du Latin-1 est une grosse régression.
Tout est expliqué ici => https://dev.mysql.com/doc/refman/8.0/en/charset.html
Il faut utiliser les bonnes fonctions :Citation:
Il faut savoir que l'UTF8MB4 utilise de 1 à 4 octets pour stocker 1 caractère, ce qui peut provoquer inutilement des problèmes dans la longueur des chaînes de caractères
-- LENGTH() = nombre d'octets
-- CHAR_LENGTH() = nombre de caractères
Les autres fonctions comme SUBSTRING() ou POSITION() gèrent cela de manière transparente.
Il n'y a aucune régression à utiliser le Latin1 (ou ISO-8859-1) puisque tu as tous les caractères dont tu as besoin pour écrire en français. Je ne vois pas ce que l'UTF8 peut t'apporter en plus.
L'inconvénient de l'UTF8 est de produire une volumétrie supérieure à celle du Latin1 pour la même quantité de caractères dans un texte.
Le "SET NAMES" par défaut est en Latin1, pas en UTF8. Tout comme la collation par défaut est Latin1_Swedish_ci.
Non, car pour le français le tri sera incorrect. Il faut utiliser une collation française. Pour l'anglais LATIN1 c'est OK, car pas d'accents. Pour un mélange de langues latines, il faudra piloter les tris en ajoutant une clause COLLATE fonction de la langue manipulée...Citation:
Envoyé par Artemus24
A +
Non, l'UTF8 est très mal géré par MySQL qui utilise systématiquement 3 octets pour 1 caractère... Ce qui limite par exemple les index à environ 256 caractères....Citation:
Envoyé par Séb.
Cela enfle artificiellement les bases et rejaillit immanquablement sur les sauvegardes, la maintenance, etc...
A +
Si si, il y a bien une régression puisque le paramétrage par défaut depuis des années est UTF-8 et qu'avec Latin-1 tu te LIMITES aux caractères dudit charset, un sous-ensemble. Pire, tu décrètes que JulienDev75 DOIT utiliser Latin-1 sans même connaitre son besoin.Citation:
Il n'y a aucune régression à utiliser le Latin1 (ou ISO-8859-1) puisque tu as tous les caractères dont tu as besoin pour écrire en français. Je ne vois pas ce que l'UTF8 peut t'apporter en plus.
UTF-8 permet d'utiliser n'importe quels caractères et autres emojis pour un coût faible. Il y a 1 an j'ai dû utiliser des caractères polonais, grâce à UTF-8 des Ł et des Ę n'ont posé aucune difficulté.
Il n'y a pas de SET NAMES par défaut côté serveur. Il y a des paramètres serveur par défaut, tous en UTF depuis des années. Il y a aussi des serveurs et des clients mal paramétrés. Les mauvais réglages client peuvent être outrepassés par le serveur.Citation:
Le "SET NAMES" par défaut est en Latin1, pas en UTF8. Tout comme la collation par défaut est Latin1_Swedish_ci.
Il existe des mots ayant des caractères accentués dans le dico anglais, des restes du Français.Citation:
Envoyé par SQLpro
Je suppose que les anglais/américains s'en soucient encore moins que nous.
La doc dit :Citation:
Non, l'UTF8 est très mal géré par MySQL qui utilise systématiquement 3 octets pour 1 caractère...
Ton affirmation me semble au mieux datée. Je suis preneur de toute doc technique à ce propos.Citation:
MySQL supports these Unicode character sets:
-- utf8mb4: A UTF-8 encoding of the Unicode character set using one to four bytes per character.
-- utf8mb3: A UTF-8 encoding of the Unicode character set using one to three bytes per character. This character set is deprecated in MySQL 8.0, and you should use utfmb4 instead.
-- utf8: An alias for utf8mb3. In MySQL 8.0, this alias is deprecated; use utf8mb4 instead. utf8 is expected in a future release to become an alias for utf8mb4.
Peut-être un mal pour un bien.Citation:
Ce qui limite par exemple les index à environ 256 caractères....
Il ne manque plus que l'argument écologique. Bref, je ne vois pas ce qu'il y a d'artificiel, c'est le comportement normal et connu d'UTF-8 => Le texte pèse davantage. J'accorde qu'il pèse tellement plus pour certains jeux de caractères exotiques que cela limite son utilisation face à des jeux spécialisés. Avec nos caractères latins on n'a pas à se plaindre.Citation:
Cela enfle artificiellement les bases et rejaillit immanquablement sur les sauvegardes, la maintenance, etc...
C'est plus simple de tout faire en UTF-8. Même si on n'utilise que du français, ce ne sera pas forcément vrai demain et de toute façon il y aura toujours des éléments qui sortent du cadre.Citation:
Envoyé par Artemus24
Je m'en suis rendue compte il y a quelques années avec une application pour recueillir des commentaires bruts, où il y avait des smilies, des émojis... On aurait pu essayer de filtrer ce genre de chose (encore que, ce n'est pas si simple !) mais la volonté était vraiment de ne rien modifier aux commentaires reçus.
Il faut prendre en considération le front-end aussi. Si on a une application web moderne, les pages HTML et donc les formulaires seront habituellement en UTF-8. Si on envoie de l'UTF-8 à une DB qui tourne dans un charset différent, on risque d'avoir des problèmes avec les accents, en clair des pertes de données et de sens, à moins de gérer la conversion en amont, ce qui n'a pas de valeur ajoutée. Il faut penser ce problème de charset (et de collation) du début de la chaîne jusqu'à la fin.
Il me semble que ce problème a été corrigé avec la version 8 de MySQL, me fourvoyais-je ?Citation:
Envoyé par SQLpro
Salut à tous.
@ JulienDev75 : le mieux est de consulter le Blog de SQLPRO à ce sujet.
@ SQLPRO : je préfère de loin utiliser le LATIN1 dans mes bases de données car il répond à mes besoins.
Tout comme sous Windows, j'utilise windows-1252 qui est une adaptation du latin1, enfin je devrais plutôt parler de l'ISO-8859-1.
Mon principale critère est d'avoir la volumétrie la plus faible en fonction des caractères utilisés.
Pour ce qui est du tri, je n'ai pas constaté de gros problèmes dans le respect de l'ordre de classement du français.
Pour ce qui est de la casse, je préfère un tri sans accents et de ce fait "latin1_general_ci" me convient.
A quoi pensez vous en disant cela ?Citation:
Envoyé par SQLPRO
D'où ma préférence dans le choix du Latin1 puisque 1 caractère = 1 octet et répond à une volumétrie plus faible que l'UTF8.Citation:
Envoyé par SQLPRO
Entièrement d'accord. :)Citation:
Envoyé par SQLPRO
Pourquoi voulez vous m'imposer l'UTF8 alors que le LATIN1 répond à mes besoin ?Citation:
Envoyé par Seb.
Je n'ai besoin que des caractères utilisés dans la langue française et de l'anglais.
Je n'ai aucun besoin d'un alphabet différent du latin.
Je n'ai rien décrété du tout. J'ai juste dit que la seule question que l'on doit se poser est le choix de la langue utilisée.Citation:
Envoyé par Seb.
Comme SQLPRO le fait remarquer, et moi-même, le cout en volumétie n'est pas du tout faible.Citation:
Envoyé par Seb.
Parce que votre problème est différent du mien. Je ne comprends cette volonté de vouloir tout faire en UTF8 même quand cela pose des problèmes de volumétie.Citation:
Envoyé par Seb.
Vu votre réflexion, je crois que vous n'avez pas compris à quoi sert le SET NAMES.Citation:
Envoyé par Seb.
Quand on envoie un jeu de caractères vers le serveur MySql, le client MySql doit préciser par le paramètre "SET NAMES", le jeu de caractères utilisés.
Si ce CHARSET n'est pas pris en charge par le serveur, celui-ci va considérer que c'est le CHARSET par défaut qui sera utilisé.
Lisez cette page MySql consacré aux erreurs des charset de connexions.
C'est la solution de facilité.Citation:
Envoyé par BinaryGirl
J'utilise WampServer et tout est en latin1. C'est normal car c'est moi qui gère cela.Citation:
Envoyé par BinaryGirl
Ce n'est pas forcément le cas chez un hébergeur qui ne va pas faire de la spécificité pour un client.
C'est ce que j'ai fait et chez moi, ça fonctionne bien. :)Citation:
Envoyé par BinaryGirl
La norme est au UTF8MB4 qui utilise au maximum 4 octets pour coder 1 caractère.Citation:
Envoyé par Escartefigue
Avec un moteur InnoDB, la limite est de 767 octets, ce qui correspond à 255 caractères en UTF8 et à 191 en UTF8MB4.
Comment trouve-t-on ces deux nombres :
767 / 3 = 255,66.
767 / 4 = 191,75.
ce qui voudrait dire que MySql prend systématiquement 3 octets en UTF8 et 4 octets en UTF8MB4.
Et après vous vous demandez pourquoi je n'utilise pas UTF8.
Cordialement.
Artemus24.
@+
latin1 character est le charset par défaut dans MySQL jusque 5.7. A l'origine c'était même latin1_swedish_ci, puisque le produit vient de Suède...Citation:
Envoyé par Artemus24
Aujourd'hui le charset par défaut dans MySQL 8 est utf8mb4.
De nos jours, je ne suis pas sûre que l'argument de la volumétrie est déterminant, surtout avec le storage qui est bon marché, les disques SSD qui deviennent la norme, et le cloud et les snapshots incrémentaux...
Quand je fais un dump Mysql à backuper, je le zippe d'abord. Et je ne suis pas certaine que le résultat final sera très différent selon que les tables sont définies en latin1 ou utf8mb4, mais c'est un test qu'on peut faire.
En réalité, c'est rare qu'on ne traite qu'une seule langue à la fois. En fait, on ne le remarque pas car même en étant en CP1252 (ou ISO-8859-1), on peut encaisser pas mal de caractères non-français.
Même si c'était vrai ce ne sera pas forcément le cas demain.
Sur les sites que je gère il y a des clients de monde entier, et ils ne se privent pas de mettre leur adresse dans leur alphabet natif (ex: coréen). D'ailleurs il est malaisé pour eux de faire autrement car ils n'ont pas le même clavier que nous.
Toutefois, la question du stockage des données est distincte de la collation à appliquer.
Encodage et stockage sont deux choses différentes. L'encodage UTF8 est à "pas variables". Certaines lettres (les 128 du jeu ASCII de base) sur 1 octet, d'autres (latin, grec et cyrillique) sur 2 octets, langues orientales, arabe, hébreu... sur trois octets... et ainsi de suite. Cependant et pour des raisons de tri, classement, comparaisons, unicité en fonction de la collation, MySQL ramène tout à 3 octets ou 4 suivant le jeu choisi.... par caractères...
Lire : 10.9.1 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)
A +
Je suis en MySql version 8.0.33.Citation:
Envoyé par Binarygirl
Si je regarde le CHARSET du système (character_set_system), il est en "UTF8MB3" et je ne peux pas le modifier.
Ce qui est en défaut mais modifiable est le CHARSET "UTF8MB4" de la création des bases de données.
Si tu stockes des émoticônes, tu es obligé d'utiliser la collation "UTF8MB4". Ils sont stockés sur 4 octets.
La langue internationale est l'anglais, ma langue maternelle est le français, ça fait deux.Citation:
Envoyé par Binarygirl
Chez un hébergeur, il est plus facile de tout mettre en "UTF8MB4".
En ce qui me concerne, je ne vais pas commencer à utiliser le chinois, l'arabe, le cyrillique, ou l'araméen, et je ne sais quoi d'autres comme alphabet que je ne connais pas.
La langue est une barrière, surtout si l'on n'arrive pas à la lire à cause de son alphabet. En dehors de sa langue maternelle et de la langue internationale, je me demande s'il existe des combinaisons de plusieurs langues sur des sites, dans le cadre professionnel.
Bien sûr, les forums internationaux, les réseaux sociaux où chacun converse dans sa langue et son alphabet... ainsi que les sites e-commerce. Par exemple, sur le chat du service clientèle, toutes sortes de langues sont utilisées. On ne peut certainement pas se limiter à l'alphabet latin.Citation:
Envoyé par Artemus24
Et il y a aussi les emojis.
Ou alors il faut expliquer aux clients/utilisateurs pourquoi leur input (dans les zones "texte libre") n'est pas enregistré correctement sur le site et qu'ils se retrouvent avec de la bouillie dans leur texte parce que certains caractères ne passent pas. Ce qui est une cause de frustration. Les utilisateurs s'en fichent de nos soucis de volumétrie, de chatset ou des choix techniques, ils veulent juste que ça maaaarche :)
Tout dépend donc des utilisateurs (langue, culture...) de la nature du dev (web ou Win form) et des développeurs, qui pour la grande majorité ne savent pas programmer des composants qui limitent la saisie à l'essentiel...
A +