自定义字段/属性模型答案

【问题标题】：Custom fields / attributes model自定义字段/属性模型
【发布时间】：2012-10-13 04:41:06
【问题描述】：

我需要在预订软件中实现自定义字段。我需要扩展一些表，例如，包含具有动态属性的用户组。

还有一个产品表，其中每个产品都可以有自定义字段（理想情况下，这些字段可以嵌套）。

我已经对 EAV 进行了一些搜索，但我读到了很多负面的 cmets，所以我想知道该使用哪种设计来处理这类事情。

我了解使用 EAV 会导致许多连接对产品页面进行排序，但我不想在每次创建属性时更改组/产品表。

注意：我使用 Innodb

【问题讨论】：

AFAIK，没有灵丹妙药。这都是关于权衡的。关键问题是您将如何处理这些数据。 “无限灵活”的数据需要同样无限灵活的 UI 和大量用例。我会从用例开始，然后在固定模式中尽可能多地实现，添加尽可能少的 EAV 扩展，并权衡例如 XML 字段。
另外，根据经验，可以使用数据库元数据生成许多与 EAV 相关的查询。将其添加到等式中。
谢谢。是的，应该可以搜索具有给定属性的产品，它在创建“动态表”时增加了一些复杂性

标签： mysql sql

【解决方案1】：

唯一好的解决方案几乎是您不想做的事情，每次创建属性时都更改组/产品表。是的，这很痛苦，但它可以保证数据的完整性和更好的性能。

如果你不想这样做，你可以用TableName, FieldName, ID and value创建一个表，然后说：

TableName='Customer'，FieldName='Address'，ID =1（客户 ID），值 ='客户地址'

但正如你所说，它需要大量的连接。我认为这不是一个好的解决方案，我已经看过但不会真正推荐它。只是展示，因为它是一种可能的解决方案。

另一种解决方案是在您的表上添加几个预定义的列，例如 column1, column2, column3 等，并根据需要使用它们。这是一个和前一个一样糟糕的解决方案，但我见过使用它的主要 ERP。

伙计，根据经验，您在该区域找到的任何东西都将是一项巨大的工作，不值得实施，您必须维护它的麻烦将比将字段添加到表中更大。保持简单和正确。

【讨论】：

谢谢。我需要看看这个解决方案。我正在阅读另一篇文章，其中有人谈论每种产品一张桌子。我认为它避免了有很多空字段。使用这种方法，用户界面看起来像 phpmyadmin
每个产品一个表？你的意思是？（只是对我的回答添加了一点小评论）
好的，我低估了你的场景的复杂性。可以说，您需要的是每种类型的产品一张桌子。是的，您提供的链接包含两个非常好的方法

【解决方案2】：

您可以通过添加至少 2 个表格来做到这一点。一个表将包含属性唯一键 (attr_id) 和属性值，例如属性名称和业务逻辑所需的其他内容。

第二个表将作为您的产品表和属性表之间的连接，并应具有以下字段：

(id, product_id, attr_id)

这样，您可以添加任意数量的动态属性，并且您的数据库架构将是未来的证明。

现在查询的唯一缺点是必须再添加 2 个要连接的表。

【讨论】：

【解决方案3】：

我正在开发一个完全基于 EAV 的项目。我同意 EAV 让事情变得复杂和缓慢，但它有它自己的优势，比如我们不需要更改数据库结构或代码来添加新属性，并且我们可以在数据库表中的数据之间建立层次结构。

如果我们在所有地方都使用 EAV，系统会变得非常慢。

但是，如果使用得当，Eav 非常有用。我永远不会基于 EAV 设计我的整个数据库。我将划分常用和有用的属性并将它们放在平面表中，而对于附加属性（可能需要根据客户或各种要求进行更改），我将使用 EAV。

通过这种方式，我们可以拥有 EAV 的优势，其中包括您想要的灵活性，而不会遇到太多麻烦。

这只是我的建议，也许有更好的解决方案。

【讨论】：