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

Question

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

可以肯定地说，Eav/CR数据库模型不好。尽管如此，

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

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

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

进一步讨论：

长话短说，是否有任何链接在互联网或模型描述，可以“学术上”修复以下设置？我感谢诺埃尔肯尼迪提出了一个类别表，但可能需要更多。下面我用不同的方式来描述它，试图强调它的意义。我可能需要一个观点修正来解决这个问题，或者我可能需要深入到Eav/CR。

喜欢对Eav/CR模型的积极反应。我的同事们都说了JeffreyKemp在下面提到的：“新的实体必须由专业人员建模和设计”(脱离上下文，阅读下面的回应)。问题是：

• 实体每周添加和删除属性

  
  (搜索关键字指定未来属性)

• 新实体每周抵达

  
  (产品由零件组装)

• 旧实体每周离开

  
  (存档，不那么受欢迎，季节性)

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

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

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

Answer 1

可以肯定地说，Eav/CR数据库模型是不好的。不，不是。这只是因为它们对关系数据库的使用效率很低。一个纯粹的密钥/值存储非常适合这个模型。现在，真正的问题是：如何存储各种属性并保持它们的可搜索性？用Eav就行了。在您的情况下，它将是一个额外的桌子。对属性名和属性值进行索引，大多数RDBMS都会对属性名重复使用前缀压缩，使其非常快速和紧凑。当您使用Eav/CR替换“REAL”字段时，它会变得很难看。与每一个工具一样，过度使用它是“不好的”，并给它一个不好的形象。