A “post relationship” is the connection between different posts in a website. When we say “post”, we mean not only blog posts, but particularly “custom post types”.
Three possible types of post relationships exist:
Before we give the formal definitions for these, we must first understand when a post relationship is used. Then, the different kinds of relationships will appear to be trivial.
Using a post relationship makes building advanced sites and running them easier.
Building a site using related posts allows you to separate information into independent pieces, which can then be combined in multiple ways. You can eliminate data duplication, enabling you to edit each piece of information only once and use it in any manner you desire.
These are the essential principles of good database design. They are true for both large and small sites.
Does this sound confusing? Let us examine how it all looks in practice.
We will build a cooking recipes site (i.e., nothing sophisticated).
Our site will include:
For example, to prepare an “onion and mushroom omelet,” we need eggs, onions, and mushrooms. However, you cannot make an omelet without a pan and stove.
We can build a fine-looking cooking recipe site using only blog posts. In each post, we will present the ingredients and explain how to mix them.
Nothing bad here, right?
Now imagine that we want visitors to our site to be able to search for vegan recipes (i.e., those that do not have eggs as an ingredient). How can we implement such a search?
Or, imagine if we “go wild” by allowing visitors to compile shopping lists based on recipes. How are we going to accomplish this? Remember, the list of ingredients is simply a series of lines in a blog post.
Or, better yet, let us say that we have established an affiliate relationship with some equipment vendors and want to link them with affiliated links. How can we update all these links in our old posts?
These are difficult questions to address.
We can create the same site using custom types and connect them. Obviously, we will set up custom types for recipes, ingredients, and equipment. We also know that each recipe requires many ingredients and pieces of equipment and that these ingredients and equipment are used in multiple recipes.
Therefore, we need to set up a relationship that looks something like the following:
As you can imagine, we will need to establish many-to-many relationships between recipes and ingredients as well as between recipes and equipment, and so on. Suddenly, this does not sound too technical anymore.
Now begins the fun part. We will have eggs as an ingredient in many of our recipes. Fortunately, we need to make eggs in our site only once. We will proceed by creating an “eggs” entry under the “ingredients” custom type.
Similarly, we will create “onions” and “mushrooms” as well as “pan” and “stove”.
Note that when we describe our “onion and mushroom omelet” in our post, we are not reinventing the wheel (nor the egg, nor the onion!). We will connect the ingredients for the recipe and the equipment required to make it. The recipe does not repeat other information; it only describes how to make this specific dish. See the difference?
How to create a search for recipes based on ingredients has yet to be described, but you can probably imagine that it easy to accomplish. We can prepare the lists of ingredients for recipes and use our affiliate link when listing the equipment needed to prepare dishes. We will get to the “how” in a minute.
As we just learned, we need many-to-many relationships in which each item connects to several items. This is the case for recipes and ingredients: a recipe has many ingredients and an ingredient is needed for many recipes.
One-to-many relationships are equally popular and intuitive. If you create a “map of the world” site, you will need to show continents, countries, counties, cities, and streets. A country can be in one continent and a continent can have several countries (yes, the Australian continent has only one country, but the concept still applies).
Thus, continents and countries have a one-to-many relationship.
We can also consider a one-to-one relationship. A door has at most one door handle (doors without handles can exist, but a door with two handles cannot).
A quick glance suggests you should always use many-to-many relationships. Although one-to-many seems to be a particular case of many-to-many, this is not the case. Understanding the difference and choosing the right relationship for each case is crucial.
The WordPress “page parents” are a good example of one-to-many relationships. Pages can have one “parent” and a parent can have many “children.” A page cannot have more than one parent.
Therefore, parents are given a special status. Using page parents, we can create hierarchical menus and breadcrumbs. If pages are connected using many-to-many relationships, a way to trace pages up through their parents to the site’s root would not be possible. You would not be able to show a breadcrumb trail or design meaningful menus.