A quick primer on meta, because twitter sucks for discussions

onmeta.txt

It's like this...

There's nothing wrong with meta tables, in general. They convert the normal relational 
database principles into a way to store data using key/value pairs. And they scale fine, 
if you use them for the purpose in which they were designed.

Meta tables store information about "things". They're connected to another table which 
contains the things that they're storing information about.

So if I have a post, then storing arbitrary information about that post is perfectly 
acceptable for meta key/values, in postmeta. Similarly, if I have users, then storing 
info about them in usermeta is great.

However, the assumption here is that you're getting this data about a specific "thing". 
The system doesn't scale when you start wanting to get all the "things" that have a 
particular meta. 

Specifically, this is because meta_value is not indexed. Which is actually the correct 
way to do it, because the assumption is that the value here is meaningful and probably 
not shared. That is, I'm storing, say, a description of a person in their usermeta, or 
a link to their facebook profile, or something about that person. I'm not storing "abc" 
for every single person, or some group of them.

When you start getting into "grouping" things by some characteristic, then that's where 
you start needing to switch to a custom taxonomy instead. You can group things (posts, 
users, etc) by the same system as post-tags use. They can be defined on the fly too, 
like tags are. The difference here is that taxonomy assumes that there are a limited 
number of unique items for each taxonomy, and that it is not arbitrary.

This difference may seem non-existent, but it's really crucial. Meta defines 
characteristics about some thing. Taxonomy groups those things with other like-things.

And tax-queries are f'ing fast by comparison to meta queries. The nature of there being a 
limited potential set of "tags" allows the query to be optimized specifically for searching
like that. 

So, bottom line, if you need to query for a group of things (posts, users, etc) that all 
have something in common, then that thing they have in common should have been a tag to 
start with. If you need to actually get the value and display it or manipulate it, but not
search based on it, then it should be in meta. And if you need both, then it should be in 
both and you need to have code to change both of them appropriately when the situation changes.

Note that special cases are special, and there is nothing inherently wrong with using your 
own table if needed. But meta is fine for the designed purpose: as an arbitrary key/value 
storage for "things".

-Otto

Additional: I said much the same thing, but in the opposite direction, a couple years ago:
http://ottopress.com/2011/when-to-not-use-a-custom-taxonomy/

I find that the problems people have with meta, or with taxonomy, are invariably when they choose the wrong one that fits their current goals. This isn't one-size-fits-all here, you need to think about how you're going to use the data you're storing first, not just where you want to store it. Then decide.

Yeah taxonomy sounds cool for an option vs custom fields, except when it's not just a normal varchar (like something needing longtext / date / datetime / int / etc)

Scott's issue is where the lines get muddy for me. when the data being stored isn't a simple varchar, but still needs to be used in a query (usually date based). I guess for those, the speed hit is just the cost of doing business.

Dates are one of those special cases, because it's both info you need and info you search by. Both meta and taxonomy don't handle it. In such cases, make a special table. But for most of the rest, it can be done normally.