Dans le cadre de la gestion de partenaires, nous envisageons l’utilisation d’une notion de tag pour qualifier le “rôle” dudit partenaire dans les relations avec l’entreprise.
En effet un même partenaire peut cumuler plusieurs qualifications. Les qualifications actuellement identifiées couvrent les notions de champs d’intervention (sanitaire, logement, formation, …), de périmètre (national, local, déclinaison local d’un partenaire national) et des notions spécifiques (taxe d’apprentissage, mécénat). Ces qualifications sont susceptibles d’évoluer et doivent donc être administrables (création, désactivation).
L’approche la plus adaptée semble être de représenter ces tags sous forme d’un objet de référence avec une relation N-N aux partenaires.
=> La question qui se pose est la mise en œuvre d’une recherche multi-critères.
Le besoin est qu’un utilisateur puisse filtrer les partenaires d’après un ensemble de tags.
Par exemple je souhaite obtenir la liste des partenaires concernant la “Formation” identifiés au “National” qui contribuent à la “Taxe d’apprentissage”.
Idéalement pouvoir ajouter ou retirer un tag des critères pour affiner/rectifier la liste des résultats.
Merci pour votre retour d’expérience sur le sujet.
Il y a 2 notions dans Simplicité de liens multiples :
Le type d’attribut énumérés multiples :
une seule colonne en base qui concatène les choix utilisateurs séparés par des “;”
présenté en cases à cocher ou select multiple
recherche de type “OR” (votre besoin semble être un “AND” il faudra passer par du code pour écraser le OR par défaut sur le champ)
Relation N,N :
stockée dans une table avec 2 foreign-keys
peut s’afficher en pillbox pour faire croire à “un seul champ” dans une liste
une pillbox est adaptée pour lister des pays par exemple, on reste dans une même sémantique d’objet
pas de recherche possible pour le moment, c’est en cours d’étude car :
Il reste à modéliser différentes règles de matching entre 2 ensembles (mes choix vs les références):
comme un “like” sur la clé fonctionnelle de l’objet lié (tous les pays qui contiennent “fr”),
ou un choix variable parmi toutes les références possibles :
ET : contient (strictement ou pas) les éléments recherchés (comme France et Espagne),
OU : contient au moins 1 (France ou Espagne ou Suisse)
MIXTE : France et Espagne ou Suisse
ou plus complexe : au moins 8 tags parmi les 23 que je coche dans une table de 3000 références sur un écran responsive…
La recherche de “tags” au sens large est donc non triviale et ne répond jamais au cas général de mélanger des torchons et des serviettes au début, puis ensuite aller y chercher des chaussettes dépareillées seulement le dimanche… Tout mélanger dans une seule notion/champ reste peu modélisé.
Mon conseil est donc que la notion de tag “fourre tout” reste à éviter quand c’est possible / votre besoin semble modélisable :
type d’intervention : sanitaire, logement… 1 liste administrable
niveau : national, local… une 2eme liste
périmètre : formation, taxe … 3eme liste
Chaque colonne pouvant dès lors avoir sa propre logique de filtrage disjoint/optionnel/cumulatif.
Si c’est un problème de présentation, vous pouvez concaténer tous ces champs ENUM dans un seul champ calculé/en lecture si vous voulez les avoir ensemble sur la liste (voir en recherche fulltext), mais il faut toujours ranger les notions métiers de façon claire quelque part dans un modèle en 3eme forme normale = champs accessible dans l’écran de recherche mais masqué en liste par exemple.
L’apparente simplicité d’un nuage de tags cache toujours une complexité sur toutes les renormalisations dans tous les systèmes connexes (requétage SQL, import, export…) et leur évolutivité.
Les tags sont à voir comme un champ commentaire, donc il faut y classer des données non structurantes (non indéxées, non requetables, non validables…).