[wp-hackers] Rebuttal (re: Meta tables: Take 5)
Peter Westwood
peter.westwood at ftwr.co.uk
Fri Jul 24 15:46:24 UTC 2009
On 24 Jul 2009, at 16:38, Jacob Santos wrote:
> 1. With proper indexes, performance problems shouldn't be an issue.
> Having millions of rows in majority of cases shouldn't hinder most
> of the use cases with the correct indexes to search on.
> 2. I would probably state that having multiple meta tables for each
> blog would be a good idea as it doesn't have to be tied to just all
> of the blogs for a single table but for a single blog for MU
> installations.
> 3. It is in my opinion that having multiple tables with the same
> structure and tiny amount of rows is even worse design than a single
> table. Alas, a compromise can probably be found between a single
> table and multiple tables.
>
> I will contend that for the majority of non-MU and plain WordPress
> installations, having a single meta meta table will never even get
> close to reaching 100,000 rows, let alone the millions that would be
> required to degrade performance.
Agreed
I was very careful in my proposal [1] to talk about an api which was
db structure agnostic, because they may be arguments both ways and I
think the storage mechanism should be completely separate from the api
and it is really the api we need to decide on first!
Once we have actually got some data about what is being stored and
what is being queried there may be cases when a object type specific
meta table is required but I would expect that for 80% of use cases a
single table would be fine.
For what its worth bbPress is built around a single meta table [2]
(which even the options go in)
westi
[1] http://blog.ftwr.co.uk/archives/2009/07/23/a-better-meta-api-for-wordpress/
[2] http://trac.bbpress.org/browser/trunk/bb-admin/includes/defaults.bb-schema.php#L28
--
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
More information about the wp-hackers
mailing list