Question

Alongside the users table, WordPress has a usersmeta table with the following columns

• meta_id
• user_id
• meta_key (e.g. first_name)
• meta_value (e.g. Tom)

Each user has 20 rows in the usersmeta table, regardless of whether or not the rows have a filled-in meta_value. That said, would it not be more efficient to add the always-present meta rows to the users table?

I’m guessing that the information in the users table is more frequently queried (e.g. user_id, username, pass), so it is more efficient to keep those rows smaller. Is this true? And are there other reasons for this separation of tables?

Answer 1

Entity Attribute Value

It’s known as the Entity Attribute Value (EAV) data model, and allows an arbitrary number of attributes to be assigned to a given entity. That means any number of meta-data entries per user.

Why use it

By default there are a few keys that wordpress sets (20 stated in the question) but there can be any number. If all users have one thousand meta data entries – there are simply one thousand entries in the usermeta table for each user – it doesn’t have (in terms of the database structure) a limit to the number of meta data entries a user can have. It also permits one user to have one thousand meta data entires, whilst all others have 20 and still store the data efficiently – or any permutation thereof.

In addition to flexibility, using this kind of structure permits the main users table to remain small – which means more efficient queries.

Alternatives

The alternatives to using EAV include:

• Modify the schema whenever the number of attributes changes
• Store all attributes in a serialized string (on the user object)
• Use a schemaless db

Permissions is the biggest problem with the first point, it is not a good idea to grant blanket access to alter the schema of your database tables, and is a (sane) roadblock for many if not most wordpress installs (hosted on wordpress.com or on a shared host where the db user has no alter permissions). Mysql also has a hard-limit of 4096 columns and 65,535 bytes per row. Attempting to store a large number of columns in a single table will eventually fail, along the way creating a table that is inefficient to query.

Storing all attribute in a serialized string would make it difficult and slow to query by a meta-data value.

WordPress is quite tied to mysql, and therefore changing datastore isn’t a realistic option.

Further WP info

If you aren’t using any/many plugins it’s possible you will have a constant number of rows in the usermeta table for each user, but typically each plugin you add may need to add meta-data for users; the number added may not be trivial and this data is stored in the usermeta table.

The docs for add_meta_user may add some clarity as to why the database is structured that way. If you put code like this somewhere:

add_user_meta($user_id, "favorite_color", "blue");

It will create a row in the usermeta table for the given user_id, without the need to add a column (favorite_color) to the main users table. That makes it easy-ish to find users by favorite color without the need to modify the schema of the users table.