Abfrage, um “Eltern” -Beiträge von CPT A zu finden, während “Kind” -Beiträge von CPT B gefiltert werden

Nehmen wir an, wir haben zwei CPTs, eine von Städten und eine andere von Restaurants. Jedes Restaurant befindet sich in einer Stadt (duh) und serviert verschiedene Arten von Lebensmitteln, unterschiedliche Öffnungszeiten, unterschiedliche Preise usw. Jedes Restaurant hat die Post-ID der Stadt in einem “Stadt” -Meta-Feld, und der Rest der Eigenschaften sind in andere Meta-Felder.

Mein Ziel ist es, etwas wie “alle Städte, in denen es italienische Restaurants gibt, die am Sonntag geöffnet sind” zu bekommen, mit Paginierung nach Städten.

Dies muss natürlich skalieren, denn in jedem Land gibt es viele Städte und Restaurants. (Ja, die Analogie ist tatsächlich in der Skala der DB wird sein)

Eine Möglichkeit, dies zu tun, ist, nach Restaurants zu suchen und sie dann nach Städten zu gruppieren, aber das klingt nach etwas, das bei einer trivialen Suche (alle Restaurants, die am Montag geöffnet haben) leicht Speicher überfließen kann.

Grundsätzlich suche ich nach einer Möglichkeit, zwei Abfragen zu verbinden, aber jede andere Idee ist willkommen

Solutions Collecting From Web of "Abfrage, um “Eltern” -Beiträge von CPT A zu finden, während “Kind” -Beiträge von CPT B gefiltert werden"

Diese Meta-Abfragen werden teuer sein, und die Antwort herauszufinden und zwischenzuspeichern ist eine schlechte Lösung. Warum also nicht zur Wurzel des Problems gehen und die Datenstruktur anpassen?

Ihr coredatentyp ist das Restaurant, und Sie möchten filtern / abfragen, so dass Taxonomien gemeint sind. Warum also nicht eine Standort- / Städte-Taxonomie? Nur weil Sie einen Stadtposttyp haben, bedeutet das nicht, dass Sie auch keine Stadt- oder Gebietstaxonomie hinzufügen können. Strukturiere es hierarchisch über continent -> country -> province -> city .

Jetzt ist Ihre Suche eine Suche nach Restaurants mit einer tax_query , die die Stadt angibt. Tun Sie dies für jedes Kind in einer Provinz / Land und Sie haben, was Sie wollen.

Abgesehen davon vermeidet dies immer noch nicht Meta-Abfragen, die das performancesproblem Nummer 1 sind, die Sie mit einem großen Vorsprung konfrontiert werden. Alles, was Sie gerade als Post-Meta speichern, das Sie filtern oder nach denen Benutzer suchen, muss eine Taxonomie sein oder eine Entsprechung haben. ZB können Sie für die Preise Bereiche von “10-20 € pro Person” usw. anlegen, die Nutzer dann danach suchen lassen, anstatt einen genauen Wert einzugeben.

Das Endergebnis wird Ihnen also geben:

  • Eine Seite, die, wenn sie einen Begriff in der Lokationstaxonomie erhält, die tiefsten Kindbegriffe ergreift und dann über sie hinwegschleift
  • Für jedes dieser Kinder heißt es
    • Anfragen für Restaurants in diesem Zeitraum, die den anderen Suchparametern entsprechen, mit maximal 4 oder 5 Restaurants aus performancesgründen
    • Wenn welche gefunden werden
      • Zeigt den Titel des Begriffs / der Stadt an
      • Zeigt die Ergebnisse der Suche und einen Link zu einer vollständigen Ergebnisseite an

Ich würde auch folgende Dinge empfehlen:

  • Verwenden Sie pre_get_posts , dies gibt Ihnen pre_get_posts kostenlos, legen Sie einfach die Suche Benutzeroberfläche an der Spitze der Vorlage, wenn Sie das Taxonomie-Archiv für die Städte / Standort Taxonomie verwenden können, dann noch besser!
  • Taxonomien Taxonomien Taxonomien Taxonomien, verwenden Sie keine Post-Meta-Abfragen. Wenn Sie die Skalierbarkeit und performance dieser Seite tun, wird dramatisch fallen. Eine einzelne Meta-Abfrage kann eine Website mit hohem Datenaufkommen zum Absturz bringen. Wenn Sie für jede Stadt eine Website erstellen, dauert das Laden dieser Seite sehr lange

Schließlich, bedenken Sie, dass, nur weil Sie dies abfragen können, bedeutet nicht, dass Sie sollten. Für eine effiziente Datenstruktur mit schnellen Seitenladungen müssen Sie entscheiden, welche Einschränkungen akzeptabel sind. Je mehr Freiform Ihre Daten sind, desto teurer werden Ihre Abfragen oder desto mehr Daten müssen Sie duplizieren und approximieren. An einem bestimmten Punkt benötigen Sie Elastic Search, um eine mittelmäßige performance zu erzielen, wenn Sie alles abfragen möchten.

Nehmen Sie UX-Entscheidungen vor, um zu ändern, wonach ein Benutzer suchen kann, und zwar auf eine Weise, die Ihnen hilft, aber dem Benutzer nicht das verwehrt, was er möchte. B., dass der Benutzer eine vordefinierte Preisspanne oder -bereiche auswählen kann, anstatt ihnen ein Eingabefeld zu geben, das eine beliebige Zahl akzeptiert (Schieberegler können die nächsten € 5 fangen) und eine teure Meta-Abfrage in eine schnellere Taxonomieabfrage umwandeln.

Wenn Sie Städte brauchen:

Hinweis in meta_value können Sie alles hinzufügen …

 meta_id bigint(20) unsigned Auto Increment post_id bigint(20) unsigned [0] meta_key varchar(255) NULL meta_value longtext NULL 

Sie können den Meta-Wert für Italien haben und Sie können die CityID auf einem anderen Meta setzen.

Die Paginierung basiert auf $wp_query global. Um die query_posts zu erhalten, müssen Sie lediglich query_posts am Ende Ihrer query_posts ausführen und bevor die Paginierungsfunktion für die Seitenumbruch-Links korrekt ist.

Die Argumente für diesen query_posts müssen alle Stadt-IDs enthalten, die Sie beim Durchsuchen der Restaurants erhalten haben.


Wenn Sie Restaurants benötigen und sowohl Stadt als auch Restaurant sind CPTs, können Sie zwei Abfragen erstellen, oder eine verschachtelte Abfrage, um alle italienischen Bürger-IDs zu erhalten, über die Abfrage mit dem Parameter 'fields' => 'ids' .

Dann holen Sie sich alle Restaurants mit City IN Liste dieser IDs.

Das klingt einfach für mich.