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

Question

可以肯定地说 EAV/CR数据库模型不好。也就是说，

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

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

在优秀的电子商务应用程序中有一个很好的共同特征，它们显示一组产品，然后有“向下钻取”的侧边菜单，您可以在其中看到“电视分辨率”作为标题，以及前五名最常见的电视搜索结果的解决方案。你点击一个，它只显示该分辨率的电视，允许你通过选择侧面菜单上的其他类别进一步深入。这些选项将是在运行时添加的动态产品属性。<​​/p>

进一步讨论:

长话短说，Internet 上是否有任何链接或模型描述可以“从学术上”修复以下设置？感谢 Noel Kennedy 建议的类别表，但可能需要比那更大。我在下面以不同的方式描述它，试图突出其重要性。我可能需要修正视点来解决问题，或者我可能需要更深入地了解 EAV/CR。

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

• 实体每周添加和删除属性
  (搜索关键字决定 future 的属性)
• 新实体每周到达
  (产品由零件组装而成)
• 旧实体每周消失一次
  (已存档，不太受欢迎，季节性)

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

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

属性一定要有意义，不能只是关键字搜索。如果他们想比较所有带有“鲜奶油糖霜”的蛋糕，他们可以点击蛋糕，点击生日主题，点击鲜奶油糖霜，然后检查所有有趣的蛋糕，因为它们都有鲜奶油糖霜。这不是蛋糕特有的，只是一个例子。

Answer 1

我能想到一些一般的优缺点，在某些情况下一个比另一个更好:

选项 1，EAV 模型:

• 优点:设计和开发简单应用的时间更少
• 优点:易于添加新实体(甚至可能 由用户添加？)
• Pro:“通用”界面组件
• 缺点:验证简单数据类型所需的复杂代码
• 缺点:简单的 SQL 复杂得多 报告
• 缺点:复杂的报告几乎可以 不可能
• 缺点:大型数据集性能不佳

选项 2，分别为每个实体建模:

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

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

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

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

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