sql - 为什么 Wordpress 有单独的 'usersmeta' 和 'users' SQL 表。为什么不把它们结合起来呢？

Question

除了 users 表，Wordpress 还有一个包含以下列的 usersmeta 表

• 元标识符
• 用户编号
• 元键(例如名字)
• 元值(例如 Tom)

每个用户在 usersmeta 表中有 20 行，无论这些行是否具有填充的 meta_value。也就是说，将始终存在的元行添加到用户表不是更有效吗？

我猜测 users 表中的信息被更频繁地查询(例如 user_id、username、pass)，因此将这些行保持较小会更有效。这是真的？这种表格分离还有其他原因吗？

Answer 1

实体属性值

它被称为 Entity Attribute Value (EAV) 数据模型，并允许将任意数量的属性分配给给定实体。这意味着每个用户有任意数量的元数据条目。

为什么要用

默认情况下，wordpress 设置了几个键(问题中规定为 20 个)，但可以有任何数量。如果所有用户都有一千个元数据条目 - 每个用户的 usermeta 表中只有一千个条目 - 它没有(就数据库结构而言)用户可以拥有的元数据条目数量限制.它还允许一个用户拥有一千个元数据整体，而所有其他用户拥有 20 个元数据并仍然有效地存储数据 - 或其任何排列。

除了灵 active 之外，使用这种结构还允许主用户表保持较小的规模——这意味着查询效率更高。

备选方案

使用 EAV 的替代方法包括:

• 每当属性数量发生变化时修改架构
• 将所有属性存储在序列化字符串中(在用户对象上)
• 使用无模式数据库

权限是第一点的最大问题，授予一揽子访问权限以更改数据库表的架构不是一个好主意，并且对于许多(如果不是大多数)wordpress 安装(托管在 wordpress 上)来说是一个(理智的)障碍.com 或在 db 用户没有更改权限的共享主机上)。 Mysql 也有一个硬限制 4096 columns and 65,535 bytes per row .尝试在单个表中存储大量列最终会失败，同时创建一个查询效率低下的表。

将所有属性存储在序列化字符串中会使通过元数据值查询变得困难和缓慢。

Wordpress 与 mysql 紧密相关，因此更改数据存储不是一个现实的选择。

更多 WP 信息

如果您没有使用任何/许多插件，您可能会在每个用户的 usermeta 表中拥有固定数量的行，但通常您添加的每个插件可能需要为用户添加元数据；添加的数字可能不是微不足道的，此数据存储在 usermeta 表中。

add_meta_user 的文档可能会更清楚地说明为什么数据库是以这种方式构建的。如果你把这样的代码放在某处:

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

它将在 usermeta 表中为给定的 user_id 创建一行，而不需要向主用户表添加一列 (favorite_color)。这使得通过最喜欢的颜色找到用户变得容易，而无需修改用户表的架构。