通常在制作Wordpress网站时,我只使用post meta来扩展自定义帖子,并且我使用自定义分类法进行基本查询。我理解为什么这是使用每个元素的正确方法,元比税等更昂贵,但我从来没有在WP中超出此范围的项目。然而,我正在研究我自己的一个想法,我需要它从一开始就运行绝对完美和优化。我花了好几个小时试图找出这个,所以来到这里要求第二个意见。
我有产品的帖子类型和接受此产品的服务的其他帖子类型。所以假设产品是20厘米x 30厘米x 10厘米,我想匹配所有将携带此产品的服务。
我添加了3个元字段高度,宽度和深度。然后,我进入了查询第二个帖子类型的阶段,并决定通过post meta值查询可能是错误的方法来解决这个问题?这是一个例子。
'meta_query'=> array(
'relation' => 'AND',
array(
'key' => '_target_width',
'compare' => '>=',
'value' => get_post_meta( get_the_ID(), '_product_width', true ),
'type' => 'numeric'
),
array(
'key' => '_target_height',
'compare' => '>=',
'value' => get_post_meta( get_the_ID(), '_product_height', true ),
'type' => 'numeric'
),
这可以吗?我有疑虑并且一直在想我确实需要使用分类法,因为我不确定是否可能会对大量数据进行元查询。
所以我的问题是你如何设置它?如果是税,那么我如何为具有自定义分类的查询设置键值对?或者我坚持上述?
我可能已经写了这么短,但试图尽可能详细地解释。
答案 0 :(得分:0)
元查询可能是最简单的解决方案,但在性能方面并非最佳。如果您的posts
和postmeta
表增长,则此查询可能会变得非常慢。这是因为对于您所做的每个条件,数据库查询必须创建postmeta
表的新左连接(以将此字段的数据作为查询中的单独列加载),这可能会变慢大桌子。
我已经学会了这种方法,试图在具有几种不同条件的大型数据库中查询用户元素。
至于使用分类法 - 我认为性能与此特定案例的后元查询类似。
因此,如果性能是优先级,我建议为服务目标创建一个单独的数据库表,其中包含以下列:
service_id -> foreign key to the service's post ID
target_width
target_height
target_depth
这样做的缺点是您将无法使用默认的WordPress后置查询方法来加载帖子或存储目标大小,但您必须为此创建自定义数据库查询,因此这需要一些使用mysql的经验。
如果您使用此选项,您仍然可以使用post meta作为产品帖子,除非您必须按这些字段查询帖子(就像您必须使用服务帖子一样)。
因此,它肯定需要更多的工作,但这种解决方案在性能方面应该要好得多。
但是,如果创建单独的数据库表不适合您,您需要在使用post meta和taxonomies之间进行选择,则需要考虑以下事项:
postmeta
表增长多少进行一些预测 - 许多插件倾向于将大量数据存储为post meta,所以如果是这种情况,如果表格较小,加载分类法可能会更快>=
等查询的功能,因此您仍然需要创建自定义数据库查询来加载帖子我希望这有帮助!