When developing plugins that requires data storage, what’s the pros and cons of using one method or another ?
The explanation given in the codex is not detailed:
Before jumping in with a whole new
table, however, consider if storing
your plugin’s data in WordPress’ Post
Meta (a.k.a. Custom Fields) would
work. Post Meta is the preferred
method; use it when
possible/practical.
Well, if I take the hat of a WP script kiddie, my answer would be: use post_meta, always.
However, I happen to know a thing or two about databases, so my answer is: never, ever, ever, use an EAV (aka the post_meta table) to store data that you might to need to query.
On the index front, there are basically none worth using in meta tables. So, if you’re storing data type XYZ and are hoping you query all posts that have XYZ with a value of 'abc', well… good luck. (See all of the users/roles/caps related tickets in the WP trac to give you an idea of how gory it can get.)
On the join front, you quickly crash into the limit at which the optimizer decides to use a generic algorithm instead of analyzing the query when there are multiple join criteria.
Thus, no, no, no, no. Don’t ever, ever, ever use a meta. Unless what’s you’re storing is cosmetic and will never be part of a query criteria.
It breaks down to your app. If you’re storing, say, the birthdate of a movie director, than big deal. Use a meta all you want. But if you’re storing, say, the release date of a movie, you’d be nuts to not use a separate table (or adding columns to the posts table) and add an index to that column.