可以肯定地说，EAV/CR数据库模型是糟糕的.也就是说，
问题:What database model, technique, or pattern should be used to deal with "classes" of attributes describing e-commerce products which can be changed at run time?
在一个好的Electron 商务数据库中，您将存储选项类(比如TV分辨率，然后每个TV都有一个分辨率，但下一个产品可能不是TV，也没有"TV分辨率").如何存储它们、高效搜索并允许用户使用描述其产品的变量字段设置产品类型？如果搜索引擎发现客户通常根据控制台深度搜索电视，则可以将控制台深度添加到字段中，然后在运行时为每种电视产品类型添加一个深度.
在好的Electron 商务应用程序中有一个很好的共同特点，它们显示一组产品，然后有"向下搜索"的侧菜单，在那里你可以看到"电视分辨率"作为标题，以及找到的一组最常见的五种电视分辨率.你点击其中一个，它只显示该分辨率的电视，允许你通过 Select 侧菜单上的其他类别进一步深入.这些选项将是在运行时添加的动态产品属性.
Further discussion:
长话短说，我感谢诺埃尔·肯尼迪(Noel Kennedy)提出了一个分类表，但需要的可能不止这些.下面我用另一种方式来描述它，试图强调它的重要性.我可能需要一个观点修正来解决这个问题，或者我可能需要深入研究EAV/CR.
我喜欢EAV/CR模式的正面react .我的开发伙伴们都说Jeffrey Kemp在下面提到的话:"新实体必须由专业人士建模和设计"(脱离上下文，阅读下面他的回答).问题是:
- entities add and remove attributes weekly
(search keywords dictate future attributes) - new entities arrive weekly
(products are assembled from parts) - old entities go away weekly
(archived, less popular, seasonal)
客户希望为产品添加属性有两个原因:
- 部门/关键字搜索/同类产品之间的比较表
- checkout 前的消费品配置
属性必须具有重要意义，而不仅仅是关键字搜索.如果他们想比较所有有"奶油奶油霜"的蛋糕，他们可以点击蛋糕，点击生日主题，点击奶油霜，然后判断所有有趣的蛋糕，知道他们都有奶油霜.这不是蛋糕特有的，只是一个例子.