在过滤CPT A的“子”帖子时查询CPT A的“父”帖子

Question

假设我们有两个CPT，一个是城市，另一个是餐馆。每家餐厅都位于一个城市，提供不同种类的食物、不同的时间、不同的价格等。每家餐厅都在“城市”元领域中拥有城市的岗位ID，其余的属性在其他的元领域。

我的目标是能够做到这样的事情：“让所有的城市，其中有意大利餐馆在星期日开放”，按城市分页。

这显然需要扩大规模，因为每个国家都有许多城市和餐馆。(是的，这个类比实际上是在DB将要达到的规模上)

在我脑海中出现的一种方法是搜索餐厅，然后将它们按城市分类，但这听起来很容易让我在琐碎的搜索(周一开放的所有餐馆)中内存溢出。

基本上，我所寻找的是一种连接两个查询的方法，但任何其他想法都是受欢迎的。

Answer 1

这些元查询将是昂贵的，找出答案并缓存它是一个糟糕的解决方案，那么为什么不找出问题的根源并调整数据结构呢？

您的核心数据类型是餐厅，您希望筛选/查询，这意味着分类，那么为什么不拥有一个位置/城市分类法呢？仅仅因为您有一个城市post类型，并不意味着您也不能添加一个城市或地区分类法。通过continent -> country -> province -> city分层构造它。

现在，您的搜索是一个具有指定城市的tax_query的餐馆搜索。在一个省/国家里，每个孩子都要这样做，你就能得到你想要的。

顺便说一下，这仍然不能避免元查询，这是您将面临的第一个性能问题。您目前存储为post元的任何内容，如果要让用户进行筛选或搜索，都必须是分类法，或者具有相应的功能。例如，对于价格，您可能会列出“每人10-20欧元”等范围，然后让用户按此搜索，而不是输入一个精确的值。

所以最终结果会给你：

• 当在位置分类法中给定一个术语时，获取最深的子术语，然后遍历它们的页面。
• 对于每一个子术语，它都是
  • 查询该术语中与其他搜索参数匹配的餐馆，出于性能原因，最多查询4或5家餐馆
  • 如果有发现，
    • 显示术语/城市的标题
    • 显示搜索结果和指向完整结果页的链接。

我还建议以下几点：

• 使用pre_get_posts，这将为您提供免费分页，只需将搜索UI放在模板的顶部，如果您可以使用城市/位置分类法的分类法存档，那就更好了！
• 分类，不要使用后元查询。如果您这样做，此页面的可伸缩性和性能将急剧下降。一个元查询可以减少一个流量很大的站点，如果您在这里为每个城市做一个，那么这个页面需要很长时间才能加载。

最后，考虑这一点，仅仅因为您可以对此进行查询，并不意味着您应该这样做。对于具有快速页面加载的高效数据结构，需要确定哪些约束是可以接受的。数据越自由，查询就越昂贵，或者需要复制和近似的数据越多。在某个时候，如果你想要查询任何东西，你就需要弹性搜索来达到甚至平庸的性能。

做出UX决定，改变用户可以搜索到的内容，这些方式可以帮助您，但不要否认用户的需求。例如，让用户选择一个或多个预定义的价格范围，而不是给他们一个接受任何数字的输入框(滑块可以按最近的欧元5，将一个昂贵的元查询转换为一个更快的分类查询，其中提到多个术语)。

Answer 2

如果你需要城市：

注意在meta_value中你可以添加任何东西..。

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

您可以拥有意大利的元值it，也可以在另一个元上设置CityID。

分页是基于$wp_query全局的。因此，为了获得分页，只需在搜索模板的末尾和分页函数之前执行query_posts，以确保分页链接是正确的。

这个query_posts的参数必须包含在搜索餐馆时获取的所有城市ID。

如果您需要餐馆，并且City和Restaurant都是CPT，您可以通过带有'fields' => 'ids'参数的查询创建两个查询或一个嵌套查询来获取所有意大利citie ID。

然后得到所有拥有城市IN的这些ID的餐馆。

这对我来说很简单。