Dans les recherches, possibilité d'éviter la saisie des wildcards *

Dans les recherches, possibilité d'éviter la saisie des wildcards *
0
Tags: #<Tag:0x00007fec5884fdb8>

Bonjour,

Une remarque revient régulièrement chez les prospects. Ils ne comprennent pas pourquoi saisir les * dans les critères de sélection (cette obligation leur semble obsolète, outre le fait que la recherche globale ne l’impose pas).

Est-il possible d’apporter une solution à ce problème d’ergonomie ?

Merci d’avance et bonne après-midi

Marc Marquizeau

Bonjour,
je confirme ce retour utilisateur (sans chercher à détourner ce post de la question initiale).

La mise à disposition de l’assistant de recherche ([…] à côté) est très appréciée mais très souvent, les utilisateurs saisissent un terme de recherche en faisant l’hypothèse que la règle appliquée sera “contient” par défaut.

Il faudrait néanmoins un mécanisme simple permettant d’expliciter le cas de recherche “exacte” (i.e. sans les ‘*’ de part et d’autre) comme une case à cocher à côté du champ, décochée par défaut.

Merci pour votre retour,

Oui au premier usage ce n’est pas intuitif de saisir des wildcards (* ou _), surtout si on ne passe pas par le bouton d’aide “…” prévu à cet effet. Un besoin corollaire est de trouver les records sans accent, tolérance aux fautes de frappe, etc jusqu’à finir par intégrer un moteur google ou elastic-search basé sur Lucene.

Mais bon tous les ERP du marché ont ce fonctionnement car il faut mettre ce besoin en regard du SQL sous-jacent et des dégradations de performance associées, bref faire des compromis fonction vs coûts temps/volume.

La recherche par colonne doit à mon avis rester “fine” et à la main de l’utilisateur, car il existe déjà une recherche globale fulltext et de la completion par champ même sur un champ de recherche. Le champ “libellé du bien” peut être paramétré en completion pour afficher une dropdown des valeurs basées sur un “contient”.

Une recherche de type “contient” par défaut signifiera techniquement faire une recherche dans toute la table / car tout index non unique sur la colonne ne servira alors à rien (column like ‘%texte%’ = fullscan) donc au final une dégradation totale des performances de recherche sur toutes les (grosses) tables.

  • Il est envisageable de faire un “commence par” par défaut (et pas un égal) car une indexation simple sur la colonne pourra être utilisé, mais comme indiqué par Bruno, il faudra un nieme bouton pour activer/désactiver ce mode, encore plus compliqué à comprendre pour l’utilisateur.

  • Sinon si le champ dépasse une certaine taille, nous devrons étudier si l’usage d’un index “fulltext” est possible sur chaque colonne typée en recherche (et sur postgresql, mysql et oracle uniquement) permettant des recherches “contient” plus ou moins floue (phonème, accents…) et doublant potentiellement la taille physique de chaque colonne pour garantir de bonnes performances.