[Gelöst] Design principle – creating tens of thousands of relationship instances

[Author]

Artikel

[alexG-4]

I'm re-designing the structure of my site.

A core post-type will be Topics, and there will be several hundred of them.

I also want to use the names of those Topics to "tag" other content. There will be around 15 post types I'll want to tag in this way.

There will be several thousand posts across those 15 post types.

One option would be to not use Tags at all, but to create a relationship between a post and the Topic post(s) I want to 'tag' it with - but I'm concerned that there might be performance issues with tens of thousands of relationship instances being created.

Another option is to create normal tags alongside the Topics, and use normal tagging (although I may also want to create relationships with some of the post types.) The problem with that is I'll have a Tag page AND a Topic page for each of the terms.

The third option would be to NOT use a post-type for the Topics, but to ONLY use Tags. The trouble with that option is that I want to have detailed control over the layout of the view of each Topic, including displaying summaries of the 'related' / tagged content. Also, I expect I'll want to include data within some of the relationships, so I think this option is a non-starter.

What high-level advice would you give? And especially, would there be performance issues with a large number of relationship instance in the first option?

Many thanks

Alex

[Minesh]

Hello. Thank you for contacting the Toolset support.

If we rule out Toolset totally here, even with only WordPress, with such mass content having more than tens of thousands of posts WordPress will also have performance issues. I'm not saying it will not work but it may have impact on performance based on the number of taxonomies, relationship and what filters you add to your view.

In general, performance obviously affects the site speed when you have that many custom post type setup having thousands of posts with the number of taxonomies as well as custom fields. One aspect is how much content you have BUT it depends also on your server configuration (memory,cashing) as well as number of other factors such as how complex your data structure is.

Here is the related ticket where I explain this in bit more detail.
- https://toolset.com/forums/topic/performance-with-large-amount-of-data-and-indexing-issue/#post-2265513

Here is our official Doc about how you should use views with large sites:
- https://toolset.com/documentation/legacy-features/views-plugin/how-to-use-views-parametric-search-on-large-sites/

All in all, its kind of try and test situation where you will have to be really sure with what kind of structure you would like to go with.

[alexG-4]

Hello Minesh

Thanks for that - very helpful, and sobering!

Specifically on the issue of filtering on taxonomy values vs custom field values vs relationships... I note that you said taxonomies are fast and custom fields are slow - but what about relationships?

For example, does toolset_get_related_posts have to search through all posts of the related post type, or is there an index of related IDs?

Alex

[Minesh]

Toolset relationship stored in custom tables but with tens of thousands of posts in relationship, it will again raise a question.

For instance, lets assume you have One To Many Post relationship between post type A (parent) and B (child).
Now, You connected thousands of posts of related posts of post type B(child) to post post type A(parent). So to search within those thousands of posts it will again question of how powerful your server resources like memory, CPT etc..etc.. could be.

As shared, in such a complex case you will have to run a test and see what filter will suits your need the bests, custom field, taxonomy or post relationship.

[alexG-4]

My issue is resolved now. Thank you!