Demande de conseil :
 
Dans une db MySQL j'ai une colonne qui contient du texte.  
 
Sur une des lignes, la colonne contient "fosse" et sur une autre ligne cette colonne contient "fossé" (accent sur le dernier caractère).  
 
Quand j'exécute un select avec un where la colonne en question = "fosse" il me sort les deux lignes (je vois bien une valeur sans accent et l'autre avec).
 
Idem quand je fais la requête sur "fossé"
 
Je souhaiterais distinguer les deux valeurs : une fosse c'est un trou alors qu'un fossé c'est un contrebas d'une route et mes utilisateurs font bien la différence.  
 
Comment puis-je paramétrer MySQL pour que je puisse distinguer les deux valeurs ?  
 
J'ai fait un test complémentaire :  
J'ai créé une table de travail et j'ai créé une colonne en varchar en tant que clé primaire et unique (en fait c'est pléonasme mais peu importe).  
Insertion de la valeur "fosse" => ok
Insertion de la valeur "fossé" => ko  cause de la primary key
 
Je modifie la valeur en "fossé" => ok (et elle réapparait bien avec l'accent)
Insertion de la valeur "fosse" => ko.  
 
Certaines recherches semble indiquer que l'encodage que j'utilise (utf8_unicode_ci) n'est pas sensible aux accents (ni à la casse).  
 
Mon souhait est que je puisse distinguer les deux valeurs, c'est à dire que la DB soit sensible aux accents. Par ailleurs, je souhaite que cette DB reste insensible à la casse.
 
Des idées ?
 
Merci pour votre aide éventuelle.

Il me semble que "_ci" dans "utf8_unicode_ci", qui signifie "case insensitive", s'applique aussi accents qu'aux minuscules / majuscules en fait.
 
Avec un encodage binaire, ça devrait régler ton problème (mais en créer bien d'autres lors de comparaisons).
 
Tu peux peut-être utiliser les deux encodages (deux colonnes, l'une en case insensitive, l'autre en binaire), et utiliser l'une ou l'autre en fonction de tes besoins.

Merci pour ton retour qui confirme l'analyse que nous faisons avec l'équipe en place.
 
J'ai d'autres contraintes qui sont de conserver l'insensibilité à la casse.  
 
Un peu par hasard, j'ai trouvé une solution qui me convient mais il faut qu'avec mon DBA on approfondisse ma solution et les problèmes qu'elle induit.
 
Elle consiste à conserver l'encodage tel qu'il est, cependant au moiment des recherches sur cette colonne, dans l'ordre select, ajouter sur quel encodage je veux travailler. Et comme par hasard, l'encodage qui dans ce cas précis m'arrange est le utf8_bin.  
 
Précisément mon ordre SQL donne cela :  
 
select a.categorie_type, a.categorie_value  
from fsn_categorie a
where a.categorie_value = "fossé"
COLLATE utf8_bin;

Attention à la sensibilité à la casse (majuscules / minuscules) dans ce cas, et vérifier le comportement de fonctions type LowerCase / UpperCase avec des accents.

C'est bien vu, merci.