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 post_id
, meta_key
and 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_date
, post_excerpt
and we can utilize them to store data for those post types.
Examples:
- Instead of storing a paragraph in a custom field (like song lyrics), we can store it in
post_excerpt
. - Instead of using a custom field for order date, we can use
post_date
. - Instead of storing testimonial author name in a custom field, we can use
post_title
.
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.
Real examples
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)
- Uses
post_status
for 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
- Use
post_title
for 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).
Conclusion
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.
Leave a Reply