Performance 具有自定义字段的实体数据库性能设计

我需要构建一个有通用实体（比如文章、页面、节点）的应用程序，用户可以在其中添加自定义字段

我已经看到了最流行的PHPCMS（wp，drupal）用来实现这个目标的方法；它们都具有具有最小字段（例如标题和正文）的基表，然后将所有其他字段委托给其他表，例如：

table node
id | title | body

table field_foo
node_id | field_type | field_value

table field_bar
node_id | field_type | field_value
// and so on

这在一个完整的mvc环境中是非常合乎逻辑的；现场控制器分别处理每个现场

但是说到性能，加载单个节点将需要许多queryes或许多联接

我采取了一种不同的方法（即使是因为我的应用程序不提供任何基本字段）：对于每个字段，我在基本表上添加一个新列来存储原始值，然后为每个需要它的字段（例如多个字段，或对其他实体的引用）添加一个表，以及一个只包含索引实体| id | field |id的关系表（该表实际上执行其他类型的工作，如跟踪版本和实体之间的关系）

因此，通过一个查询，我从一个实体获取所有原始数据，然后字段控制器知道（在需要时）如何以及在何处加载该字段的实际值

数据表（table_entity_data）中的列类型是字段数据的最佳猜测：对于文本是文本，对于decimal是decimal；只有对于多个字段（其值在该表之外）是array（而实际数据_类型在_field_foo_value.entity_value_列中）

假设实体结构不会经常更改，我尝试对结构进行规范化

鉴于其他大型项目以非常不同的方式处理此问题，我开始怀疑我的实现，并想知道我的hibryd结构会出现什么样的问题：

table entity
id

table entity_data
entity_id | field_foo_rav_value | field_bar_raw_value

table relations
entity_id | entity_field_id | field_id_value

table field_foo_value
field_value_id | entity_value

// lets say field_bar is a single text field, there no will be another table:
// entity_data.field_bar_raw_value contains the real value

有什么建议吗

---

p、 s：我知道这个问题是很普通的，如果不合适的话，请随时标记结束。

看起来你是在发明EAV

缺点是，您正在抛弃关系数据库可以提供的所有类型安全性和结构

在理想的世界中，您可能需要：

允许建立一张合适的桌子

使用非关系数据库

不好的一面是，你放弃了关系数据库所能提供的所有类型安全和结构。嗯，不，我正确地使用了数据类型，我只是没有谈论这个。让我更新我的问题