En gros, les caractères diacritiques ne sont pas affichable, sauf l'apostrophe et le tiret. Et lors d'une recherche patient, il ne faut tenir compte ni de l'un, ni de l'autre.
Pour des recherches efficaces de personnes, il faut donc avoir l'identité sans ces caractères. Pour un affichage avec ces caractères, il faudrait donc persister la variante avec caractères diacritiques, soit, grosso modo, stocker 2x le nom et le prénom des personnes, l'une à la forme normalisée et l'autre à des fins d'affichage. Ceci, afin de limiter les doublons.
Je répondrais : LC_COLLATE. Et en Javascript : localeCompare. C'est aussi possible en Java, et même en C++
Donc : on stocke la forme officielle. Et quand on fait une recherche, on utilise la comparaison qui sait comparer des noms dans la langue.
L'identité de quelqu'un, c'est important. C'est l'outil qui doit s'adapter à l'humain, et pas l'inverse.
[^] # Re: Recherche d'antériorité
Posté par Glandos . En réponse au journal EBCDIC n'est pas compatible avec la RGPD. Évalué à 6.
Je répondrais : LC_COLLATE. Et en Javascript : localeCompare. C'est aussi possible en Java, et même en C++
Donc : on stocke la forme officielle. Et quand on fait une recherche, on utilise la comparaison qui sait comparer des noms dans la langue.
L'identité de quelqu'un, c'est important. C'est l'outil qui doit s'adapter à l'humain, et pas l'inverse.