问题描述

说我们有两个 CPT，一个城市，另一个餐馆。每个餐厅位于一个城市 (duh)，供应不同类型的食物，不同的小时，不同的价格等。每个餐厅都有一个”city” 元字段的城市的帖子 ID，其余的属性在其他元领域。

我的目标是能够做一些像 「在所有城市中有意大利餐厅在周日开放的地方」，城市分页。

这显然要在每个国家都有规模，有很多城市和餐馆。 (是的，类比实际上是 DB 的比例)

进入我心目中的一种方法是搜索餐馆，然后按城市分组，但这听起来像是可以轻松地在一个微不足道的搜索 (所有在星期一开放的餐厅) 溢出 memory 的东西。

基本上我正在寻找的是一种方式来加入两个查询，但任何其他想法都是值得欢迎的

最佳解决方案

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

您的核心数据类型是餐厅，您想要过滤/查询，以便分类，所以为什么没有位置/城市分类？只是因为你有一个城市邮政类型并不意味着你也不能添加一个城市或区域分类。通过 continent -> country -> province -> city 分层结构。

现在您的搜索是用 tax_query 的餐厅搜索，指定城市。在省/国家的每一个孩子任期做这个，你有你想要的。

除此之外，这仍然不能避免元查询，这是您将面临的第一个性能问题。您目前存储的任何您将要让用户过滤或搜索的后期元数据需要分类，或具有同等价值。例如。对于价格，您可能会制定 「每人€10-20」 的范围，然后让用户搜索，而不是输入一个精确的值。

所以最终的结果会给你：

  • 一个页面，当在位置分类法中给出一个术语时，抓住最深的孩子术语，然后循环遍历它们

  • 对于这些孩子的每个术语

    • 对于符合其他搜索参数的餐厅的查询，由于性能原因，最多可以有 4 或 5 家餐馆

    • 如果有人找到

      • 显示术语/城市的标题

      • 显示搜索结果和指向完整结果页的链接

我也建议以下事情：

  • 使用 pre_get_posts，这将给您免费分页，只需将搜索 UI 放在模板的顶部，如果您可以使用分类归档，以便城市/位置分类法更好！

  • 分类法分类法分类法，不要使用后期元查询。如果你做这个页面的可扩展性和性能将会急剧下降。单个元查询可以降低网站流量，如果您正在为每个城市做一个，那么这个页面将需要很长时间才能加载

最后，考虑这个只是因为你可以查询这个，并不意味着你应该。对于快速页面加载的高效数据结构，您需要确定什么约束是可以接受的。您的数据越多，您的查询将越贵，或者需要复制和逼近的数据越多。在某些时候，如果您想要查询任何内容，您将需要弹性搜索以达到平庸的表现。

使 UX 决定更改用户可以帮助您的方式进行搜索，但不要拒绝用户他们想要什么。例如。让用户选择预定义的价格范围或范围，而不是给他们一个接受任何数字的条目框 (滑块可以捕捉到最接近的€5，将一个价格较高的元查询转换成更快的分类法查询提及多个条款)

参考文献

注：本文内容整合自 Google/Baidu/Bing 辅助翻译的英文资料结果。如果您对结果不满意，可以加入我们改善翻译效果：薇晓朵技术论坛。