实体属性值数据库与严格关系模型电子商务

可以肯定地说EAV/CR http://en.wikipedia.org/wiki/Entity-attribute-value_model数据库模型不好。也就是说，

问题：应该使用什么数据库模型、技术或模式来处理描述可以在运行时更改的电子商务产品的属性“类”？

在一个好的电子商务数据库中，您将存储选项类别（例如电视分辨率，然后每台电视都有一个分辨率，但下一个产品可能不是电视并且没有“电视分辨率”）。如何存储它们、高效搜索并允许用户使用描述其产品的变量字段设置产品类型？如果搜索引擎发现客户通常根据控制台深度搜索电视，您可以将控制台深度添加到字段中，然后在运行时为每种电视产品类型添加单个深度。

优秀的电子商务应用程序有一个很好的共同功能，它们会显示一组产品，然后有“向下钻取”侧边菜单，您可以在其中看到“电视分辨率”作为标题，以及该应用程序的前五个最常见的电视分辨率找到设置。您单击其中一个，它只会显示该分辨率的电视，您可以通过在侧面菜单上选择其他类别来进一步深入了解。这些选项将是在运行时添加的动态产品属性。

进一步讨论：

长话短说，互联网上是否有任何链接或模型描述可以“学术地”修复以下设置？我感谢诺埃尔·肯尼迪提出类别表的建议，但需求可能不止于此。下面我以不同的方式描述它，试图强调其重要性。我可能需要修正视角来解决问题，或者我可能需要更深入地研究 EAV/CR。

喜欢 EAV/CR 模型的积极响应。我的开发同事们都说了 Jeffrey Kemp 在下面谈到的内容：“新实体必须由专业人士建模和设计”（断章取义，请阅读下面他的回复）。问题是：

• 实体每周添加和删除属性
  （搜索关键词决定未来的属性）
• 每周都有新实体到达
  （产品由零件组装而成）
• 旧实体每周消失
  （已存档、不太受欢迎、季节性）

客户想要为产品添加属性有两个原因：

• 部门/关键词搜索/同类产品对比图
• 结账前消费产品配置

属性必须有意义，而不仅仅是关键词搜索。如果他们想比较所有具有“生奶油糖霜”的蛋糕，他们可以单击蛋糕，单击生日主题，单击生奶油糖霜，然后检查所有有趣的蛋糕，因为它们都具有生奶油糖霜。这不是特定于蛋糕，只是一个例子。

我能想到一些一般的优点和缺点，在某些情况下，其中一种比另一种更好：

选项 1，EAV 型号：

• 优点：设计和开发简单应用程序的时间更少
• 优点：很容易添加新实体（甚至可能 由用户添加？）
• Pro：“通用”界面组件
• 缺点：验证简单数据类型需要复杂的代码
• 缺点：简单的 SQL 更复杂 报告
• 缺点：复杂的报告几乎可以变得 不可能的
• 缺点：大型数据集性能较差

选项 2，分别对每个实体建模：

• 缺点：需要更多时间收集 要求和设计
• 缺点：必须对新实体进行建模并且 由专业人士设计
• 缺点：为每个组件自定义界面组件 实体
• 优点：数据类型约束和验证易于实现
• 优点：SQL 易于编写、易于实现 理解并调试
• 优点：即使是最复杂的报告也相对简单
• Pro：大型数据集的最佳性能

选项 3，组合（“正确”建模实体，但为某些/所有实体的自定义属性添加“扩展”）

• 优点/缺点：收集需求和设计所需的时间比选项 1 更多，但可能不如选项 2 *
• 缺点：新实体必须由专业人员建模和设计
• 优点：以后可以轻松添加新属性
• 缺点：验证简单数据类型需要复杂的代码（对于自定义属性）
• 缺点：仍然需要自定义界面组件，但通用界面组件可能适用于自定义属性
• 缺点：一旦报表中包含任何自定义属性，SQL 就会变得复杂
• 缺点：总体性能良好，除非您开始需要按自定义属性进行搜索或报告

* 我不确定选项 3 是否一定会节省设计阶段的时间。

就我个人而言，我倾向于选择 2，并尽可能避免 EAV。然而，对于某些场景，用户需要 EAV 带来的灵活性；但这需要付出巨大的代价。