I’m building blog where users ll have option to download images. I want to display information how many times post have been displayed and how many times the image have been downloaded.
Technically I have solved this by using custom fields and it works. In near future I want to add option to sort images based on vies/downloads. Also I have solved this, but what Im thinking now is that maybe I should use custom tables instead of custom fields.
I plan to have about thousand of images, and I’m worrying if queries for displaying most downloaded/viewed images will be slow.
Use a custom table for a view counter. This is faster, easier to write, and it has fewer side-effects.
Post meta queries are rather slow. The information is stored in a way optimized for average post handling, not for custom sorting or many write accesses. Also, all post meta values are fetched each time someone asks for any field. Your data will use resources even when they arenât needed.
Sooner or later you might want to count archive views too, multiple images on one page, or downloads of archive files with more than one file. Where do you want to store that? You have much more freedom with separate tables: they are easier to extend, you can add or remove fields, tables or indexes.
Other plugins might do unexpected things with your data, so you cannot rely on it anymore.
An example: In Multilingual Press, when someone creates a translation of an existing post, I take all post meta fields (except some known built-ins) and copy those over to the other blog. I have to, because otherwise many plugins would break. But your plugin would get a wrong counter now: The new post has an incorrect view count before anyone has ever seen it.
You can protect your fields in Multilingual Press, but in other plugins, that might not be possible, or you just donât know they exist.
I have also written a small blog post about this decision with more arguments: How to store my custom values?
See also this answer: Post meta vs separate database tables