WordPress relationships functionality is not something specific only for this particular CMS but is actually a database relationship functionality. There are three types of relationships, but the combinations of those types create impressive structures.
You may ask, “Why is it important to understand them?” Well, first of all, to get to the root of what you are working with. This knowledge is essential if you make a website of nominal average complexity and higher. It gives much more freedom and a much better understanding of tools to use and to what extent.
Table of Content
What Are Relationships?
Let’s talk about relationships in two ways: a more general and technical language. So, speaking in broad terms: like everything in the world, the entire database (i.e., all the content of your website) is based on relationships. Every person on earth is an object for genealogical, professional, or personal relations: we have parents, grandparents, siblings, colleagues, etc. The same with posts, pages, categories, users, comments, etc. on the WordPress website. All of them can be interconnected with nothing else but relations.
And saying the same in more technical terms: relationships are associations between the database tables created using a joint statement to fetch specific data.
Types of Relationships
First things first, let’s have a few words about databases in general. Databases are collections of data stacked together in a logical and structured way.
We create rows and columns in the database table by creating posts, pages, users, categories, meta fields, etc. And when making the structure out of those categories, posts, and other entities, we create relationships in that database.
As a rule, relationships are built by assigning unique keys to particular rows and then linking with each other with the help of those keys. But we will not go too deep into the mechanisms and technical details because the goal is to get the main idea of this topic.
There are three types of database relationships: one-to-one, one-to-many, and many-to-many. Altogether, they allow building any hierarchy, connections, and associations.
When an object in a database is linked only to one object in another database, it’s called a one-to-one relationship. It is a simple type you can see everywhere. For example, you have a list of people with their ID numbers and names. The name and the ID number of one person create a one-to-one relationship. The same with WordPress posts: ID and Title, Title and Content, ID and Content, Title and Content (the list can go on) are examples of the one-to-one types. If objects connected like this are located on one table and even row, they are called self-joining.
In the example below, many objects are related one-to-one, for example, ID=12509 and the post title=Anne Frank. Or the Post Title and the Post Content, Post Title, and Post Name.
In our example, we also have the “book-authors” post type, and not only Anne Frank record exists there. It means that it creates a one-to-many relationship (when the book author can have many books, but a book can have only one author). The most simple example of it is taxonomies and taxonomy terms. Basically, this type is a parent-child relationship. They are created by establishing connections between two different tables with the help of a unique key.
But this type of hierarchy can be established between posts, too. And in this case, there’s no connection between two tables (because posts are stored in the same table), but it’s done a bit differently.
By default, WordPress pages can have children and parent pages. At this point, there will be a record on the database, on the post_parent column with the ID of the parent post. Or, if your custom post types can also be hierarchical, the same scenario will occur.
WordPress posts and pages are default post types with slightly different properties: posts can be grouped in taxonomies (categories and tags) but cannot have hierarchy (parent and child posts), and, in contrast, pages cannot be grouped in taxonomies, but can have parent and child pages. However, it can be changed (as well as their default set of meta fields) with the help of code snippets or plugins. Creating custom post types, we simply create an entity like a post or page, but with the custom settings and meta fields. All pages, posts, and custom posts are actually called posts on the backend and are stored in the wp_posts database table.
Another example of when a post plays the role of a parent in a one-to-many relationship type is when a post has comments and post meta (meta fields that belong to the post, e.g., thumbnails, titles, etc.). But each post meta field (or comment), from its side, creates a one-to-one relationship with the post (because meta fields or comments can belong only to one post, while the post can have many meta fields and comments).
A similar situation is with users (post authors) and their posts: one user can be an author of many posts, while the post can be created only by one user (we are not talking about revisions and edits).
And there’s no “inequality” when we have a many-to-many type of relationship. As the name suggests, multiple records in one table can relate to one or many records in another table, and vice versa. For creating such a relationship, we need a third (“join”) table to define all the links between records.
Posts and categories are the simplest examples of this relationship because one post can belong to many categories, and the category can have multiple posts.
The table storing data about such mutual connections is called wp_term_relationship, and itlinks objects_ids and term_taxonomy_ids. But the actual content of those posts (objects) and taxonomy terms are stored in their separate tables, and the wp_term_relationship table simply links them.
Creating Custom Relationships
Quite often, there’s a need to create additional relationships (except the default types, like “categories-and-posts,” “parent/child pages,” “posts-and-tags,” etc.), especially when custom post types are added to expand the website’s structure. Then plugins and the knowledge of the relationship types come in handy.
Some use cases for WordPress relationships
First of all, you need a good toolset for WordPress relationship creation. JetEngine is a fantastic plugin for dealing with custom posts and taxonomies, their relations, querying and displaying the results, and any combination of them. The interface of relationship creation is very rich in details and additional settings. Even a separate database can be created for the particular relationship to optimize the website performance (if you plan to link many items).
But let’s get down to the examples of how different types of relationships can be used.
Use cases for One-to-Many relationships
On this Medical Center website demo, we have Departments and Services. Each Service can belong only to one medical Department. That’s why there is a one-to-many relationship, where Department is a parent, and the Services is a child. After creating such a relationship, we get the block in the Department’s edit page, where we can connect the services:
Another example of a one-to-many relationship can be found on this Travel Agency Booking website between two custom post types: Countries and Tours. Countries play a role of a parent, and Tours are their children. It makes it easy to display all the tours in a particular country and apply filters.
Use cases for Many-to-Many relationships
Let’s have another example from the Medical Center website. There are many Doctors and many Services. One doctor can provide many services. And one service can be provided by many multiple doctors. So, it is definitely a many-to-many relationship.
Doctors and Services are custom post types, and we create those relationships quite easily using the JetEngine functionality.
In this particular case, this relationship has a parent one (yes, JetEngine allows to make nested relationships). It means even bigger freedom to fetch the data we need because there are special options for displaying grandchildren in this nested structure, and macros can be used for fine-tuning the query to display on the front end.
Let’s look at another example on another demo website – Bookstore Website. Here, we have Books and Promotions. There are a lot of books and various promotions. The same book can be subject to various promotions, and promotions include multiple books. So, it’s another perfect example of a many-to-many relationship type. As a result, certain books are linked to Promotion pages and vice versa.
It is the same as a many-to-many relationship when we have two items, which can have multiple relationships. A simple example is WordPress posts and categories; each category can have multiple posts, and each post can relate to multiple categories.
Yes, in WordPress, relationships between posts are pretty common. The best example is the “related posts/related products” section, frequently seen in blogs and on WooCommerce websites.
Yes, you can do it.
Relationships connect all types and pieces of content on the WordPress website. There are three types of such connections: one-to-one, one-to-many, and many-to-many. They basically put together the architecture of any site and allow us to create queries dynamically. The simplest example is when we can display many posts just by selecting one category they belong to (instead of linking each post manually).
But quite often, there is a need to establish more branchy relations than the default WordPress toolset can offer. In this case, we have to use special plugins. And such relationships become an extremely powerful feature to display, filter, and interconnect any kind of post types, meta fields, and taxonomies for the perfect user experience and for making a website efficient.