[wp-hackers] Meta tables: Take 5

[Joseph Scott]

On Aug 5, 2009, at 3:31 PM, Mike Schinkel wrote:

> Sounds like something that is only needed during a configuration  
> change which should be rare and thus not a big issue.  However, I  
> give up on that point and won't fight it.


Yeah I'd rather not have plugins that register a new meta type force a  
rebuild of the entire meta table.  For large tables that could take  
several hours.


> OTOH, I proposed a non ENUM option for those too allergic to ENUM to  
> consider it and that is factoring out the string into a linking  
> wp_meta table.  Moving forward let's please discuss option #2  
> (wp_meta) instead of ignoring it and only talking about why we don't  
> like ENUM.



I like the idea of being able to get a list of the current meta types  
by querying a very small table.  I would be concerned about the  
potential of the JOIN to kill performance in some cases:

	http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/

Having a good API could take care of this though, by keeping a  
dictionary table that listed all of the current meta types (and  
perhaps some data about them, like where they came from: WP, Plugin,  
Theme, etc.) and still storing the meta type in the meta table  
itself.  This would allow for meta queries without having to join  
against the dictionary table.

--
Joseph Scott
joseph at josephscott.org
http://josephscott.org/