When store meta data for a post type, we often think of custom fields first. This is reasonable because custom fields are born to store such custom meta data for posts.
As we know each custom field is stored in 1 row in the
postmeta table in database. If a post type has large number of custom fields (like a song has artist name, album, year, genre, length, bitrate, …), then for each post of that post type, it will take the same number of rows in the
postmeta table. The total number of rows in the
postmeta table for only that post type equals to number of posts multiplied by number of custom fields.
This is not a big problem if we has small number of posts or small number of custom fields. However, when the number of custom fields is large and your website continuously creates more posts, then the
postmeta table is getting bigger and bigger. If that happens for a long time, your database will be huge and access to the database will be much slower.
Examples of increasing database size are contact form entries, orders or bookings in ecommerce websites. The number of custom fields for these post types is fixed and quite large (order can have shipping address info, items, quantity, coupons, etc.). And the number of posts with these post types are created daily. That makes your database bloated.
The worst thing is each row added to the
postmeta table stores little information (only
meta_value). If each row can store more meta values, then we don’t need many rows.
There’s a solution to reduce number of inserted rows into the database – utilising available post fields and available data types of WordPress instead of custom fields.
That means we use available fields of the
posts table to store information with same format. The
posts table of WordPress has many fields that are rarely used for some post types such as
post_excerpt and we can utilize them to store data for those post types.
- Instead of storing a paragraph in a custom field (like song lyrics), we can store it in
- Instead of using a custom field for order date, we can use
- Instead of storing testimonial author name in a custom field, we can use
Beside post fields, WordPress has some default data types which we can utilise to add more data to post without using custom fields like comments or user fields.
To illustrate things above, let’s see some examples which are used (very smart) in reality. If you know more examples, please let me know in the comment.
1. WooCommerce order post type
- Each order in WooCommerce can has many notes, WooCommerce uses comments for these notes. Each note is a comment of the order. (I’m impressed by this method)
post_statusfor order status. They create custom post statuses. You can know how to do that in the Codex.
2. Testimonial post type
At the moment, there are some results around standards for post types, taxonomy and meta data. This is the community effort to make a standard for custom post types for plugins, themes so they can use the same data without worrying losing it when switch to another theme or plugin.
Among standalised post types, testimonial uses some post fields for meta data:
- Use avatar or featured image for customer’s image
post_titlefor customer’s name
Currently there is a plugin Testimonial By WooThemes does the same thing (although it doesn’t follow the standard above for some fields).
Utilising available post fields and data types of WordPress instead of custom fields is an effective way to reduce number of rows in the database, thereby increasing the speed of data access. However, when apply this method, you have to think carefully about which data types are suitable before using to avoid not to be changed later.