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

Question

可以肯定地说，EAV / CR数据库模型是错误的。那就是

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

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

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

进一步讨论：

长话短说， 互联网上是否有任何链接或模型描述可以“从学术上”修复以下设置？ 我感谢诺埃尔·肯尼迪（Noel
Kennedy）提出了类别表，但需求可能更大。我在下面以另一种方式描述它，以强调其重要性。我可能需要进行视点校正才能解决该问题，或者可能需要更深入地研究EAV
/ CR。

喜欢对EAV / CR模型的积极回应。我的所有开发人员都说以下是JeffreyKemp谈到的内容：“新实体必须由专业人员来建模和设计”（出于上下文考虑，请在下面阅读他的回答）。问题是：

• 实体每周添加和删除属性
  （搜索关键字决定将来的属性）

• 新实体每周到达
  （产品由零件组装）

• 旧实体每周消失一次
  （存档，不受欢迎，季节性）

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

• 部门/关键字搜索/同类产品之间的比较表
• 结帐前的消费类产品配置

这些属性必须具有重要性，而不仅仅是关键字搜索。如果他们想比较所有具有“打好的奶油糖霜”的蛋糕，则可以单击蛋糕，单击生日主题，单击打好的奶油糖霜，然后检查所有有趣的蛋糕，知道它们都有打好的奶油糖霜。这并非特定于蛋糕，仅是示例。

Answer 1

我可以想到一些一般的利弊，在某些情况下，一个要比另一个要好：

选项1，EAV型号：

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

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

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

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

• Pro / Con：收集需求和设计所需的时间比选项1多，但可能不及选项2多。
• 缺点：新实体必须由专业人员建模和设计
• 优点：以后可以轻松添加新属性
• 缺点：验证简单数据类型（用于自定义属性）所需的复杂代码
• 缺点：仍然需要自定义接口组件，但是自定义属性可能可以使用通用接口组件
• 缺点：一旦报表中包含任何自定义属性，SQL就会变得复杂

• 缺点：一般来说性能良好，除非您开始需要根据自定义属性进行搜索或报告

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

我个人将倾向于选择2，并尽可能避免使用EAV。但是，在某些情况下，用户需要EAV随附的灵活性。但这要付出巨大的代价。