Mysql 在web应用程序中实现自定义字段哪种方式更好

我在

PHP

和

MySQL

中有一个自制的web应用程序。使用我的系统的许多不同客户机希望使用自定义字段来扩充实体。每个客户机都希望存储自己的附加数据，因此这应该以动态方式完成

例如，client1希望向其产品添加“color”属性，client2希望为其产品添加一个名为“safety_level”的字段

我想要一种不仅适用于产品，而且适用于用户和任何其他实体的方法

以下是我发现的两个最佳选择，但无法决定哪一个最有效：

选项1: 对于每个实体，我创建一个

[entityname]\u customfields

表，在该表中，我以1:1的比例存储额外的字段值。 e、 g:

pro:此表的记录数不能超过实体表（在本例中为产品），这意味着记录数较少，并且很容易查看

con:添加新字段或删除旧字段需要DDL查询。我不想向用户透露DDL，甚至连拥有管理员权限的操作员也不想

选项2:

[entity]\u自定义\u字段\u值

将与

[entity]

表具有N:1关系。每行包含自定义字段的类型和值本身。在这种情况下，我们需要另一个包含自定义字段类型的表。e、 g:

自定义字段值：

+----------------------------------------------------------------------+
|products_custom_field_values                                          |
+----------------------------------------------------------------------+
|custom_field_id                                                       |
|custom_field_type (FK product_custom_field_types.custom_field_type_id)|
|value                                                                 |
+----------------------------------------------------------------------+

自定义字段类型：

+---------------------------------------------------------+
|products_custom_field_types                              |
+---------------------------------------------------------+
|custom_field_type_id (PK AUTO_INCREMENT)                 |
|product_id (FK related to products.id)                   |
+---------------------------------------------------------+

pro:管理字段很容易，不需要更改表结构

---

con:更多记录，所有类型的自定义字段值都在一个大混乱中…这没有必要出错，因为这是MySQL从一个大混乱中提取有用数据的要点。问题是效率和性能如何？

如果its是公司项目，请遵循以前项目遵循的标准

看看匈牙利符号等惯例，这比重复前缀更有意义。而且，模型名更有可能是表名

此外，如果您计划使用ORM，他们可能也有一些最佳实践

注意：本主题实际上包含在“”中，我强烈建议您阅读

我是一个懒惰的人，这意味着我倾向于应用于我的代码。这就是我的方法

所以。假设有两组产品：

ProductFoo       ProductBar
 - productID      - productID
 - name           - name
 - price          - price
 - color          - supply
 - weight         - manufacturerID
                  - safety

在这种情况下，主

产品
表中有三个常用元素。自定义参数将使用表继承进行存储（这是一件事，google it）。因此，基本上您将得到三个表：
Products
、
ProductsFoo
和
ProductsBar
，其中
Products
表有一个
“type”
字段，两个“子表”都有一个指向其父表的
productID
外键

如果您在开发时知道每个客户机需要什么“自定义字段”

现在，让我们假设客户遇到困难，希望在他们愿意的时候创建自定义字段。

在本例中，我只需创建一个
Products.data
字段，其中包含一个JSON，其中包含每个产品的所有自定义属性。当客户机希望通过自定义属性进行搜索时，仅将特殊属性“提取”到继承表中（如果客户机希望通过新的“wallywanker”属性进行搜索，则没有合理的方法索引JSON）

最终得到的是相同的基本结构，但“子表”仅包含预期可搜索的属性

我希望这是有道理的

ProductFoo       ProductBar
 - productID      - productID
 - name           - name
 - price          - price
 - color          - supply
 - weight         - manufacturerID
                  - safety