Quand utiliser la liste (texte) ou la taxonomie?


12

Cela peut être une question stupide, mais je suis curieux de savoir quel est l'avantage d'utiliser un champ de sélection multiple de liste (texte) sur un champ de référence de terme de taxonomie. Ils semblent tous deux remplir à peu près la même fonction de donner des options à choix multiples prédéterminées, mais la taxonomie a l'avantage supplémentaire de vous permettre d'ajouter des termes après que le contenu a été écrit dans la base de données.

Existe-t-il donc une bonne directive pour que l'un utilise l'un ou l'autre? (Et particulièrement lorsque la liste (texte) a plus de sens que la référence à un terme de taxonomie?).


2
J'essaie de penser à une taxonomie comme «moyen de catégoriser les données de manière structurée» (y compris les structures arborescentes) et les listes comme «offrant plusieurs options définies» lorsque l'organisation n'est pas importante. En cas de doute, je choisis la taxonomie, car l'intégration dans la navigation via Views est rapide à mettre en œuvre.
Jake The Dweeb

1
La seule chose que select / text ne peut pas faire est de structurer la hiérarchie des données; La taxonomie offre à elle seule des arbres.
Renee

Il y a un article à ce sujet sur eosrei.net/articles/2013/12/… .
colan

Réponses:


10

La structure et la dynamique sont les mots clés de l'OMI pour choisir la taxonomie. J'ai récemment eu cette question à me poser lors du marquage des entreprises avec des régions géographiques. Mon premier choix a été de préparer la taxonomie avec la liste des régions. Bientôt, cela s'est avéré être une complication excessive. Les régions ne changent presque jamais leurs noms et ne changent presque jamais leur structure / parents. J'ai donc jeté la taxonomie et décidé d'utiliser une liste plate (texte). Il est désormais beaucoup plus facile de manœuvrer les régions dans une vue. Donc - si votre liste est statique et plate - optez pour une liste.


3
Eh bien, il y a une chose évidente qui m'a échappé - je dirais utiliser la taxonomie lorsque vous voulez que les balises aient leurs propres pages, remplies de champs personnalisés, d'images, affichées dans différents modes (complet, teaser, etc.)
Artur

l'accepter car cela a donné des avantages et des inconvénients. Le point de Patrick Kenny sur la performance est également important.
Jay

8

La taxonomie a des problèmes de performances car elle évolue car les requêtes SQL s'allongent; si vous utilisez des filtres de vues, les listes de sélection seront plus rapides que la taxonomie.


C'est généralement vrai, mais avec l'expérience, vous apprenez que vous devez utiliser la recherche SOLR pour mettre à l'échelle les vues avec des filtres, donc cela n'a pas beaucoup d'importance.
Marko Blazekovic

7

Les principales différenciations que j'ai apprises sont les suivantes:

  • voulez-vous que les utilisateurs ajoutent à la liste de valeurs, pas seulement les administrateurs de site ou, l'ajout à la liste sera-t-il un besoin semi-régulier d'administrateurs de site pairs?
  • voulez-vous utiliser la valeur comme un élément organisateur de contenu lui-même (comme suggéré ci-dessus par @Artur, créer des pages de tout le contenu qui partage ce terme, avec différentes mises en page, comme une page de produit: afficher tous les vêtements XL; ou des nouvelles, afficher tous les sports)
  • les données sont-elles du tout hiérarchiques? (par exemple: sous-catégories où vous voudrez parfois capturer la catégorie parent ou les enfants séparément à d'autres)

Si non à tout ce qui précède, utilisez select / text. Si oui, utilisez des termes de taxonomie. Dans mon expérience, vous utiliserez généralement select / text. Cela fait toujours mal, mais c'est généralement vrai.


0

Le gagnant clair à mon avis serait le terme de taxonomie, plus de puissance, les petits inconvénients.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.