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

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

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

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

进一步讨论：

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

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

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

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

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

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

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

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