web-dev-qa-db-fra.com

Tax_query bat-il vraiment meta_query dans toutes les situations?

Permettez-moi de commencer à dire que je sais qu'une "tax_query" est plus rapide que "meta_query".

Il est toujours recommandé d'utiliser des taxonomies sur des méta personnalisées lorsque le filtrage par des données personnalisées est requis, mais ici je me suis retrouvé dans cette situation.

Je crée une application immobilière où j'ai ce type de propriété évidente. Chaque propriété est censée avoir X nombre de chambres et salles de bain.

Ensuite, dans mon application, vous pouvez filtrer les propriétés par plage ... par exemple: Afficher toutes les propriétés qui ont de 3 à 18 chambres.

Le moyen d'un champ personnalisé serait d'ajouter un champ personnalisé, par exemple: 'rooms' puis de faire ma requête comme:

$args = array(
    'post_type'  => 'property',
    'meta_query' => array(
        'key'     => 'rooms',
        'value'   => array(3,18),
        'type'    => 'numeric',
        'compare' => 'BETWEEN',
    ),
);
$query = new WP_Query( $args );

La taxonomie serait par exemple de créer une taxonomie personnalisée appelée 'property_rooms', puis de créer les termes comme '1', '2', '3', etc. et de faire ma requête par ID de terme comme:

$args = array(
    'post_type'  => 'property',
    'tax_query' => array(
        'taxonomy' => 'property_rooms',
        'terms'      => array(3,4,5,6,7,8,9,10,11,12,13,14,15...etc) // Just pretend these are the corresponding term id's
    )
);
$query = new WP_Query( $args );

Et voici la question: tax_query bat-il meta_query même dans des situations comme celle-ci?

Il peut être pertinent de mentionner que nous pourrions parler de milliers de propriétés.

Gardez à l'esprit que le tri par ces champs n'est ni une exigence ni une considération pour échanger la vitesse de la requête.

wp-querymeta-querytax-query
3
Luis Rivera

Tax_query bat-il meta_query même dans des situations comme celle-ci?

Non.

Les taxonomies sont appropriées si vous avez un ensemble commun de valeurs partagées par de nombreux articles et que vous effectuez une comparaison simple selon que l'article a ou non une valeur particulière. Ils sont pas appropriés si vous devez effectuer des comparaisons numériques ou de plage, comme votre exemple, ou si les valeurs vont être uniques pour chaque publication.

Voici quelques exemples de ce qui devrait et ne devrait pas être une taxonomie sur un site immobilier:

  • Type de propriété par exemple. Maison/appartement/maison de ville, devrait être une taxonomie.
  • L'achat/la location devrait être une taxonomie.
  • Caractéristiques par exemple. Animaux acceptés/Climatisation/Lave-vaisselle, devrait être une taxonomie.
  • Nombre de chambres, devrait être méta.
  • Nombre de places de stationnement, devrait être méta.
  • L'adresse doit être méta.

En plus d'être plus rapide à interroger, avoir des taxonomies pour ces propriétés facilite leur gestion dans le back-end et rend la génération d'une liste pour le filtrage considérablement plus facile et plus rapide.

Cependant, gardez à l'esprit que même si la méta est la seule option viable pour filtrer une valeur, l'utilisation d'un trop grand nombre de méta-requêtes nuira vraiment aux performances de la requête. En effet, vous interrogez en fonction de la valeur de la méta, plutôt que d'un ID, et la colonne de valeur n'est pas indexée. Cependant, ce n'est pas parce qu'il n'est pas indexé qu'il serait approprié de l'indexer vous-même. En effet, la colonne meta_value de wp_postmeta contient des types et des quantités de données très différentes pour différentes choses.

Si vous avez un grand nombre de champs numériques que vous devez utiliser pour le filtrage, ni les méta-publications ni les taxonomies ne peuvent être appropriées. Vous feriez mieux de créer une table personnalisée avec vos propres index et des types de colonnes plus appropriés. Vous pouvez ensuite stocker ces valeurs dans votre table personnalisée et utiliser le posts_clauses, ou posts_join, et posts_where filtres pour ajouter votre propre SQL à WP_Query pour utiliser votre table pour un filtrage plus efficace.

3
Jacob Peattie

Eh bien, je ne dirais pas que "tax_query bat meta_query" ... Ce sont des choses un peu différentes.

Lorsque vous effectuez tax_query, deux JOINS sont nécessaires dans votre requête SQL. Meta_query entraîne une seule jointure (si vous ne recherchez qu'une seule méta).

Alors, quand est-ce que tax_query est meilleur? Par exemple, lorsque vous recherchez des publications affectées à plusieurs taxonomies.

Disons que vous voulez trouver des propriétés qui ont 2 étages, 4 chambres, une cuisine séparée et un garage. Vous effectuez donc une recherche avec plusieurs conditions basées sur plusieurs propriétés.

Dans ce cas:

  • tax_query se traduira par une requête SQL avec seulement 2 JOINS et plusieurs conditions dans la partie WHERE.
  • meta_query entraînera une requête SQL avec 1 JOIN pour chaque propriété de votre recherche.

Et pire encore - tax_query utilise des identifiants et des clés appropriés et dans meta_query, vous devrez utiliser des chaînes comme clés. Alors oui - dans ce cas, tax_query doit être plus rapide.

Mais ... Tax_queries sont vraiment un mauvais choix si:

  • vous devez commander par sa valeur (c'est-à-dire commander les propriétés par leur prix),
  • vous recherchez toutes les valeurs dans une fourchette donnée (c'est-à-dire la recherche de propriétés dans une fourchette de prix donnée),
  • vous avez beaucoup de valeurs différentes pour une propriété donnée (c'est-à-dire le prix car il y aura presque le même nombre de prix différents que les propriétés).

Donc non - tax_query ne bat pas meta_query à chaque fois. Ce sont des choses différentes et vous devez les utiliser en fonction de vos besoins.

0
Krzysiek Dróżdż