A WordPress website can have many development stages as well as activities for optimizing its performance. However, it’s crucial to lay a solid foundation and find the optimal way to store data. So, let’s discuss this important topic here.
Table of Contents
Why Does Website Structure Matter?
At the initial stage of building any website, it can be represented as a data model where these operations take place:
- collecting data;
- storing data;
- retrieving data from the database.
Then we move to the second step, and, based on this model, we are building an interaction between this data and the user, which includes:
- displaying the stored data on the front end;
- performing operations with this data on the front end, which includes navigation, search, and filtering.
And only in the next steps of website development we finalize it by adding design elements and additional tools (SEO, analytics, marketing tools, etc.).
In many ways, the very first step defines how fast and optimized the final site will be. If some mistakes are made in the design of the data model in the beginning, then it’s very difficult to correct them later.
On this topic, I remember the statement of Pippin Williamson, the creator of Easy Digital Downloads and many other plugins. The idea was that he considered one of the biggest mistakes in the early stages of EDD development to be using a post + postmeta data model for handling orders and other EDD service entities. Over time, EDD developers were able to overcome this problem and separate service data from default posts.
WooCommerce, which has been working for a long time on moving orders from storage in post + postmeta to High-Performance Order Storage with separate tables, is facing a similar problem. These examples show how crucial it is to organize your data structure properly from the start.
So, in this presentation, I will do my best to share recommendations on how to organize your data structure correctly and avoid mistakes.
Finding the Best Way to Structure Website Data
Summary
Let’s summarize our research with a set of criteria that your data structure should meet, along with a checklist for modeling this data structure.
Criteria:
- Minimize the volume of stored data.
- Separate data for different objects into separate database tables, if possible.
- Store data based on how you plan to use it later.
Checklist on how to achieve these criteria
- Based on your task, determine which data needs to be stored. It should be the minimum set of data to implement the task – don’t store anything “just in case.”
- Then, decide where each piece of data belongs. If the data is not required on the front end – it’s better to store it in custom tables.
- Data that is required on the front end but does not use default WordPress logic – such as single posts, archives, etc. – should also be moved to custom tables.
- The rest should be stored using default WordPress entities – posts, terms, or users.
- For data needed on the front end and stored as posts, you can use hybrid optimization methods, such as moving meta fields to a separate table.
- Identify which data will be used to retrieve posts from the database or filter them.
- All data used to retrieve or filter posts that logically fit taxonomies should be stored as taxonomy terms.
- Any remaining data that couldn’t be separated into custom tables or taxonomies should be stored as a mix (as metadata in separate tables) or as regular metadata.
There will still be many questions regarding rendering optimization on the front end, caching, and more. But at least we can be confident that we are building everything on a solid foundation where all data is organized as correctly as possible within the limitations of WordPress.
