Earlier articles in this series introduced the WordPress database tables and explained which kinds of data are stored in each one. This article focuses on how those records are connected to each other. Before looking at WordPress specifically, it helps to review the three most common database relationship types:
- One-to-one: one record corresponds to exactly one other record.
- One-to-many: one record can be linked to many others, while each of those child records points back to one parent.
- Many-to-many: records on both sides can be linked to many records on the other side.
All three kinds of relationships appear in WordPress.
One-to-one relationships
One-to-one relationships are the simplest. In WordPress, some easy examples are the way a specific post ID corresponds to a single stored post record, or the way a comment ID corresponds to a single comment record. Strictly speaking, many of these examples live in the same row rather than in separate relational tables, but they are still useful for understanding the general idea.
Typical examples include a post ID and its content, a comment ID and its content, or a user ID and its username.
One-to-many relationships
One-to-many relationships are where WordPress starts to become much more powerful than a flat spreadsheet. They are usually represented by storing a unique ID in multiple related rows across another table.
For example, the post ID in wp_posts is reused inside wp_comments to show which comments belong to which post. Each comment belongs to one post, but a post can have many comments.
Other common one-to-many relationships include:
- Posts and post meta
- Posts and users (authors)
- Users and user meta
- Taxonomies and taxonomy terms
One-to-many relationships involving posts
The wp_posts table is one of the most connected tables in WordPress, and most of those links are one-to-many relationships.
Posts can be related to other posts through post_parent, which is how attachments are linked to the posts they belong to and how parent-child page relationships are stored.
Post meta lives in wp_postmeta, which stores post_id, meta_id, meta_key, and meta_value. A single post can have many meta records, but each meta record belongs to one post.
Comments live in wp_comments. Each comment belongs to one post, but a post can have many comments. Comments also have their own metadata table.
Authors are linked through the post_author field in wp_posts, which points back to the user table. A post has one author, while one user can author many posts.
One-to-many relationships outside posts
WordPress uses the same pattern in several other places as well. For example, each user can have many user meta records, and each taxonomy can have many taxonomy term records. Once you recognize the pattern, many parts of the schema become easier to read.
Many-to-many relationships
Many-to-many relationships usually require an intermediate table. In WordPress, the clearest example is the relationship between posts and taxonomy terms.
A post can belong to many categories or tags, and a category or tag can belong to many posts. WordPress handles this by connecting multiple tables together:
wp_termsstores the term names, slugs, and descriptions.wp_term_taxonomystores the taxonomy context for each term.wp_term_relationshipsstores the actual mapping between posts and taxonomy entries.
In other words, wp_term_relationships is the bridge table. It contains the post reference as object_id and the taxonomy reference as term_taxonomy_id, allowing many posts to connect to many terms.
That is why one post can have categories 1 and 3, while another post can also share category 3. The relationship is not stored directly in the post record itself; it is represented through the mapping table.
The final detail is that wp_terms and wp_term_taxonomy are effectively paired one-to-one for the structural information WordPress needs. Keeping the data split across separate tables helps the schema stay more organized.
Summary
As you can see, almost every core WordPress table participates in some kind of relationship. The main exception is wp_options, which stores site-level settings rather than relational content. Once you understand one-to-one, one-to-many, and many-to-many relationships, it becomes much easier to analyze and manipulate WordPress data in themes and plugins.
