OK, je découvre des problèmes non anticipés, merci pour le retour d'expertise. Il se peut que ça me serve un jour.
Du coup... j'ai envie de suggérer quelque chose : stocker l'identité en deux champs distincts.
1. L'identité réelle, pour affichage, pour les humains, l'État Civil.
2. L'identité normalisée pour une machine, permettant de faire des recherches.
Exemple avec Marie-Stéphanie d’Alembert:
1. Marie-Stéphanie d’Alembert
2. marie stephanie d alembert
J'y ai même mis l'apostrophe typographique dans le 1. Cette étape est faite lors du stockage. Lors de la requête, le client transforme le champ de requête en forme normalisée, envoie la requête au serveur qui n'a qu'à faire un WHERE prenom_norm LIKE '%request%';.
Les index marchent, c'est au client de se payer le coût de la transformation.
Alors... qu'est-ce que j'ai pu oublier qui viendrait contredire une efficacité de ce modèle ? ;)
[^] # Re: Recherche d'antériorité
Posté par Glandos . En réponse au journal EBCDIC n'est pas compatible avec la RGPD. Évalué à 4.
OK, je découvre des problèmes non anticipés, merci pour le retour d'expertise. Il se peut que ça me serve un jour.
Du coup... j'ai envie de suggérer quelque chose : stocker l'identité en deux champs distincts.
1. L'identité réelle, pour affichage, pour les humains, l'État Civil.
2. L'identité normalisée pour une machine, permettant de faire des recherches.
Exemple avec
Marie-Stéphanie d’Alembert:1. Marie-Stéphanie d’Alembert
2. marie stephanie d alembert
J'y ai même mis l'apostrophe typographique dans le 1. Cette étape est faite lors du stockage. Lors de la requête, le client transforme le champ de requête en forme normalisée, envoie la requête au serveur qui n'a qu'à faire un
WHERE prenom_norm LIKE '%request%';.Les index marchent, c'est au client de se payer le coût de la transformation.
Alors... qu'est-ce que j'ai pu oublier qui viendrait contredire une efficacité de ce modèle ? ;)