I don’t see any problems in you proposed schema. You might consider rolling Region and Country into one hierarchical taxonomy since they are both related to geographic location. You can leave them separate if you prefer. Go with whatever makes the most sense to you.
Be a little wary of terms stored as postmeta, such as custom fields. The WP postmeta schema isn’t very efficient. It’s typically not an issue, but if you have a very large DB and need to make frequent complex queries using postmeta as criteria, it’s going to be a rather slow query. In some cases a persistent object cache can make up for the slow queries.
It’d be more efficient to store meta data that’s frequently used in queries in a custom table where each type of meta data has its own column, instead of being related by key name. Saving meta data this way is only warranted for frequently queried data in a very large DB and caching isn’t very helpful.
Hey man, thank you for the feedback. This is very helpful!
Regarding locations. A job can be restricted for example only to North America and UK, so I’m not sure if a hierarchical taxonomy makes sense here. A job available in UK doesn’t mean it is also available in whole Europe.
I’m thinking about categorizing every country in my code (e.g. UK = Worldwide, Europe, EMEA) and then matching the job seeker’s country with the appropriate posts (e.g. country taxonomy = UK or region taxonomy = Worldwide or region taxonomy = Europe or region taxonomy = EMEA).
Does this make sense?
On the topic of postmeta and performance. I won’t have more than a few thousand job offers, so I guess I shouldn’t worry much about that?
Thanks again for your help!
Doesn’t matter if it makes sense to me, as long as it makes sense to you 🙂 It’s not what I would do, but it’s not my site. I’m thinking a location term taxonomy organized something like:
North America
--USA
----New York State
--Canada
----Quebec
EMEA
--Europe
----UK
------Scotland
------Northern Ireland
--Middle East
----UAE
You could assign terms in any quantity and at any level, so it should cover any sort of regional job coverage that might arise.
It’s hard to say at what size post meta queries would begin to show poor performance. There are several factors involved. From your schema, it doesn’t look like you would have much need to filter listings by meta data. Most data you’d filter by are all taxonomy terms, not meta data. The taxonomy schema is much more efficient than the meta data schema. A custom table for better meta data efficiency is probably unwarranted.
Thank you for the example!
I should have been more precise in what I wrote.
Take a look at this:
'Ukraine' => array('Worldwide', 'Europe', 'EMEA'),
'United Arab Emirates' => array('Worldwide', 'Asia', 'MENA', 'EMEA'),
'United Kingdom' => array('Worldwide', 'Europe', 'EMEA'),
'United States' => array('Worldwide', 'North America'),
'Uruguay' => array('Worldwide', 'South America', 'LATAM'),
'Uzbekistan' => array('Worldwide', 'Asia', 'EMEA', 'APAC'),
A country can be in multiple independent groups of countries and I don’t think the hierarchy you proposed is doable.
Taking that into account, I have one last question. Would it be better for performance to have such an array in code (like above) or better to keep in DB as metadata of taxonomy term? 😅
Like that: Worldwide, North America (Metadata) –> United States (Taxonomy Term) –> Countries (Taxonomy) –> Jobs (Post type).
In the WP database schema, taxonomies and meta data are two entirely different types of data. In the English language, sure, a taxonomic term is a type of meta data. But in WP it’s not 😉
I strongly discourage hardcoding data like this. It makes future maintenance more difficult and error prone.
What are the array elements in your schema? Terms in a “Region” taxonomy? But the individual countries are in the “Country” taxonomy? In WP taxonomies, by default you cannot relate terms of one taxonomy to those in another. You could develop a schema where it’s possible, but various taxonomies only relate through posts they are assigned to. Assigning “Ukraine” to a job listing post does not necessarily imply ‘Worldwide’, ‘Europe’, and ‘EMEA’ if they belong to a different taxonomy.
With a single hierarchical taxonomy, the ancestor terms are automatically implied by assigning a child term. One branch of such a taxonomy might be:
Worldwide
–EMEA
—-Europe
——Ukraine
You could then assign only “Ukraine” to a job listing. If a user were to query for “Europe” jobs with this schema, jobs with “Ukraine” will be found even if the “Europe” term was not explicitly assigned to the listing post. You can always alter query logic so this is not the case, but it seems like this is the behavior you’d want anyway.
In a way we’re really arguing for the same thing, but from different directions. I think my schema is a better fit than yours for how WP manages taxonomies. Yours can work, but it’ll take some custom coding to relate two different taxonomies. Mine works pretty much out of the box.
Not that it really matters, but Uzbekistan is part of EMEA? You consider the “A” to be Asia? Interesting, I thought the “A” is generally considered to be Africa.
Your solution sounds better indeed 🙂 But I’m grasping to understand how to make it work for my job board.
Consider this:
North America
–––Mexico
Latam
–––Mexico
South America
–––French Guiana
European Union
–––French Guiana
MENA
–––Egypt
–––Israel
Africa
–––Egypt
Asia
–––Israel
The above are not exceptions. There are a lot of overlaps.
So, the issue is that I need various types of country groupings – geographical, political, business, economic. And I don’t see how they can be put in a single hierarchy.
Do I duplicate the countries somehow or is there a smarter solution?
Regarding Uzbekistan. It is part of Eastern Europe according to Wikipedia, but this can be challenged I guess 😅 Thanks for bringing this to my attention – I’m going to change it.
The same term name can appear in multiple branches if necessary. It’ll have a different slug, but the visible label can be repeated. You can possibly eliminate much redundancy by how you design the various branches. For example, Mexico appearing in both N America and Latin America. You could do something like
Americas
–Latin America
—-Mexico
—-Central America
——Panama
–Canada
–USA
Yeah, there’s no N America. There’s only 3 countries there. It’s covered by assigning the 3 countries individually. I agree it is less than ideal. The alternative is have Mexico on two branches, or don’t have a Latin America term. It’s covered by assigning Mexico, Central, and S America.
Some compromise may be necessary if you wish to avoid much more custom coding to implement a schema as you initially envisioned. I’m not saying you cannot do it that way, only that it’ll take greater effort.
