Discussion :

[Invité]

Bonjour,

Dans le cadre d'un projet de migration vers 2022, nous changeons de collation serveur. Nous allons donc également faire ce changement au niveau des bases de données. Avez vous des préco, astuces pour gagner du temps pour effectuer ce changement sur plusieurs bases en même temps? Retrait des clés/indexes. Je souhaite avoir des retours d'expérience.

[SQLpro]

Pour qu'il soit effectif sur les données actuelles un changement de collation de la base nécessite un import export des données. En effet la collation fait partie du type des données. Une fois les données "stockées" dans les lignes des tables, la collation opère...
Quel est votre objectif pour un tel changement ???
Quel est la collation source et la collation cible ?

A +

[Invité]

SQL_Latin1_General_CP1_CI_AS vers Latin1_General_100_CI_AS_SC_UTF8 dans le but de pouvoir intégrer des caractères etrangers. Nous allons garder la structure de nos colonnes, juste ajuster la taille de celles ci lorsqu on changera la collation des dB pour eviter de tronquer.

[SQLpro]

Les caractères de l'ensemble des langues étrangères ne nécessitent aucunement l'utilisation d'UTF8. UTF8 est un encodage qui bénéficie à la langue anglaise uniquement et pourrie le stockage des alphabets non latin en utilisant 3 octets au lieu de deux (par exemple pour de l'arabe de l'hébreu ou du chinois...).

Pour stocker des chaines de caractères avec des langues non latines, il faut juste utiliser du NVACHAR ou du NCHAR.

Inutile donc d'utiliser de l'UTF8 pour pourrir d'avance vos performances !

A +

[Invité]

L'idée est justement de ne pas convertir l'ensemble du legacy char,varchar en nvarchar.

[SQLpro]

Encore une fois ce n'est pas le changement de collation qui vous fera cela... Ce sera juste plus complexe casse geule et contre performant.

LE SEUL MOYEN DE STOCKER DES CARACTÈRES NON LATIN EST D'UTILISER LES TYPES NCHAR et NVARCHAR.

Avant de vous lancer dans de folles modifications, il faudrait peut être commencer à se former !

Et vous vous prétendez DBA.... ça promet !

A +

[Michel.Priori]

SQL_Latin1_General_CP1_CI_AS vers [...]

Il est judicieux de ne pas continuer avec des collations dont le nom commencent par SQL_% car elles ne sont pas compatibles avec celles de Windows.
https://learn.microsoft.com/fr-fr/sq...l-server-ver16

Sur le fond, Frédéric à raison ; qu'on puisse choisir l'encodage juste en ajoutant un N devant le type est une chance, c'est tout à la fois pertinent et performant.
Du coup on ne transforme en Unicode que les colonne dont l'usage le requiert.
(sur la forme, je pense qu'il en fait des caisses juste pour garder sa signature )

D'autant plus que la collation Latin1_general s'appuie sur la page code 1252 qui comporte pas mal de caractères diacritiques.
A vous de voir si les "caractères étrangers" dont vous allez avoir besoin ne sont pas déjà supportés
https://fr.wikipedia.org/wiki/Windows-1252

Du point de vue des performances, il est plus important de typer en CHAR qu'en VARCHAR.
Le stockage est plus économe en place, donc plus performant.
De mon retour d'expérience, jusqu'à 4 caractères le type CHAR s'impose.
Au delà, faut voir au cas par cas (nb : ne pas sous estimer les gains potentiels de stocker sous forme numérique les différents "code")
En tous les cas faut chasser les infamies, produites en masse par les ORM, NVARCHAR(1) (au lieu de BIT)

Le nombre max de caractères est utile, du point de vue des perf, pour tailler les différents SET.
Utiliser des VARCHAR(max) à retour de bras est dispendieux.

Alors, oui, ce discours est très "legacy" et la jeune génération des développeurs milite pour choisir le plus généraliste et large possible.
La compréhension viendra lors des problèmes de perf
Ce qu'il y a de bien avec la technique, c'est que c'est pas la peine de s'époumoner, ça finira par arriver

[escartefigue]

@Michel, d'accord avec l'ensemble à un détail près :

Du point de vue des performances, il est plus important de typer en CHAR qu'en VARCHAR.
Le stockage est plus économe en place, donc plus performant.
De mon retour d'expérience, jusqu'à 4 caractères le type CHAR s'impose.

Pour ma part, en deçà d'une vingtaine de caractères, je n'utilise pas le varchar : non seulement l'attribut de longueur augmente de 1 à 3 octets (selon le SGBD) la taille effective de la colonne, mais en plus, le varchar provoque une fragmentation des espaces data et index en cas d'update avec modification de la longueur, et requiert un réalignement sur longueur fixe pour certaines opérations (ORDER BY, GROUP BY, DISTINCT, PARTITION BY), deux phénomènes qui plombent les perfs.

[Michel.Priori]

Pour ma part, en deçà d'une vingtaine de caractères, je n'utilise pas le varchar

Le fait qu'il y ait un seuil à partir du quel il faille procéder à des tests, nous est commun.
La conversation porte sur la valeur du seuil.

Pour prouver que c'est effectivement "rentable" de rester en CHAR, il faudrait faire des tests de perfs pour chaque colonne (et, idéalement, de bout en bout pour prendre en compte le poids du protocole qui permet de transformer le SET en un flux)
J'avoue que je ne le fait que très rarement.

Le problème que ça me pose est que l'audit se fait sur des données réelles, ne serait-ce pour pouvoir calculer la distribution des différentes longueurs de chaine.
Alors même que le concepteur implémente le type sur des présupposés.
C'est facile de corriger a posteriori !

Exemple : les codes barre (https://fr.wikipedia.org/wiki/Code-barres_EAN)
Si on exclue le code barre 128 et les add-on de l'EAN13(rare), faut-il faire un char(13) ou un varchar(13) ?

A noter : cet exemple invalide l'hypothèse de la fragmentation suite à une mise à jour ; on ne met pas/peu à jour un code barre pour en changer de norme, on crée alors un nouvel article.

Pour moi, tout dépend de l'usage effectif. On peut tout à fait imaginer qu'il n'y ait que très peu de EAN13 pour une écrasante majorité de EAN8, disons moins de 50 pour plus de 900 000 articles.
Intuitivement (donc sans avoir fait les tests) je penche pour un varchar dans cette situation.
Aussi courte soit elle, au delà de 4 caractères, je fais une analyse de la situation.