Les données de vos colonnes sont stockées à l'aide d'un jeu de caractères. Dans ce cas, il semble être utf8.
Lorsque vous travaillez sur ces colonnes (en effectuant, par exemple, des comparaisons d'égalité ou un classement), MySQL utilise une collation. Chaque colonne a un classement par défaut, qu'elle hérite du classement par défaut de la table.
Les index ont le classement par défaut de la colonne qui leur est intégré afin qu'ils puissent fonctionner efficacement.
Vous pouvez effectuer une comparaison d'égalité qualifiée par classement. Par exemple, dans un JOIN vous pouvez spécifier
ON (turkish.village_name COLLATE utf8_general_ci) = euro.village_name
ou peut-être
ON turkish.village_name = (euro.village_name COLLATE utf8_turkish_ci)
Cela devrait éliminer votre mélange illégal de collations sans vous obliger à modifier votre table. Cela peut vous aider à éviter le changement de base de données dont vous parlez. Mais attention, en utilisant le COLLATE qualificateur peut empêcher l'utilisation d'un index. Si vous avez une grande table et que vous comptez sur les index pour les performances, cela peut être inutile.
Alors, que se passera-t-il si vous modifiez vos tableaux pour changer le classement par défaut ?
- Vos données ne changeront pas (sauf si vous modifiez également le jeu de caractères). C'est bien.
- Tous les index impliquant des colonnes avec des classements seront régénérés.
- Vos comparaisons et classements peuvent changer. Je ne connais pas le turc, donc je ne peux pas vous dire ce qui pourrait casser. Mais, par exemple, en espagnol les lettres N et Ñ ne sont pas les mêmes. N vient avant Ñ dans une collation espagnole, mais dans la collation générale, ils sont traités de la même manière. Il peut y avoir certains aspects de l'alphabet turc qui fonctionnent de la même manière, donc votre
ORDER BYles résultats seront incorrects.
Mais, vous pouvez résoudre ce problème en spécifiant un COLLATE modificateur dans votre ORDER BY clause.
ORDER BY (euro.village_name COLLATE utf8_turkish_ci)
