我在PHP和MySQL中拥有自制的网络应用程序。使用我的系统的许多不同客户端想要使用自定义字段来扩充实体。每个客户都希望存储自己的附加数据，因此应该以动态方式完成。
例如 client1 想要添加＆＃34; 颜色＆＃34;属于他们的产品， client2 需要一个名为＆＃34; safety_level ＆＃34;的字段。为他们的产品。
我想要的方法不仅可以应用于产品，还可以应用于用户和任何其他实体。
以下是我发现最佳的两个选项，但无法决定哪一个最有效：
选项1：
对于每个实体，我创建一个[entityname]_customfields表，其中我将其他字段值存储在1：1中。
e.g：
+---------------------------------------------+
|products_custom_fields |
+---------------------------------------------+
|product_id (PK and FK related to products.id)|
|safety_level |
|some_other_fields |
+---------------------------------------------+
亲：这个表没有比实体表（在这种情况下是产品）更多的记录，这意味着更少的记录，并且很容易概述。
con：添加新字段或删除旧字段需要DDL查询。我不想向用户提供DDL ...甚至不具有管理员权限的运营商。
选项2：
[entity]_custom_field_values与[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) |
+---------------------------------------------------------+
亲： 管理字段很简单，不需要更改表格结构
con： 更多记录，所有类型的自定义字段值都是一大堆......这不是必要的错误，因为这是重点MySQL，从大混乱中提取有用的数据。问题是效率和性能如何？
答案 0 :(得分：2)
注意：此主题实际上已在“SQL Antipatterns”中介绍，我强烈建议您阅读
我是一个懒惰的人，这意味着我倾向于将YANGI应用于我的代码。所以这是我的方法。
因此。我们假设有两组产品：
ProductFoo ProductBar
- productID - productID
- name - name
- price - price
- color - supply
- weight - manufacturerID
- safety
在这种情况下，有三个常见元素，位于主Products表中。自定义参数将使用表继承存储（这是一个东西，谷歌它）。所以，基本上你会得到三个表：Products，ProductsFoo和ProductsBar，其中Products表有一个"type"字段和两个表表“将有一个productID外键，指向其父表。
如果您在开发时知道每个客户想要的“自定义字段”，那就是这样。
现在，让我们假设客户很难，并希望在他们想要的时候制作自定义字段。
在这种情况下，我只需创建一个Products.data字段，其中包含一个JSON，其中包含每个产品的所有自定义属性。并且当客户端想要通过该自定义属性进行搜索时，只有“提取”特殊属性到继承表（如果客户端想要通过新的“wallywanker”属性进行搜索，则没有合理的方法来索引JSON）。
您最终使用相同的基本结构，但“子表”仅包含预期可搜索的属性
我希望这是有道理的。
答案 1 :(得分：-2)
如果是公司项目，请遵循之前项目的标准。
查看匈牙利表示法等惯例，这比重复前缀更有意义。此外，您的模型名称更有可能是您的表名。
此外，如果您计划使用ORM，他们也可能会有一些最佳实践。