可以肯定地说EAV/CR http://en.wikipedia.org/wiki/Entity-attribute-value_model数据库模型不好。也就是说，
问题：应该使用什么数据库模型、技术或模式来处理描述可以在运行时更改的电子商务产品的属性“类”？
在一个好的电子商务数据库中，您将存储选项类别（例如电视分辨率，然后每台电视都有一个分辨率，但下一个产品可能不是电视并且没有“电视分辨率”）。如何存储它们、高效搜索并允许用户使用描述其产品的变量字段设置产品类型？如果搜索引擎发现客户通常根据控制台深度搜索电视，您可以将控制台深度添加到字段中，然后在运行时为每种电视产品类型添加单个深度。
优秀的电子商务应用程序有一个很好的共同功能，它们会显示一组产品，然后有“向下钻取”侧边菜单，您可以在其中看到“电视分辨率”作为标题，以及该应用程序的前五个最常见的电视分辨率找到设置。您单击其中一个，它只会显示该分辨率的电视，您可以通过在侧面菜单上选择其他类别来进一步深入了解。这些选项将是在运行时添加的动态产品属性。
进一步讨论：
长话短说，互联网上是否有任何链接或模型描述可以“学术地”修复以下设置？我感谢诺埃尔·肯尼迪提出类别表的建议，但需求可能不止于此。下面我以不同的方式描述它，试图强调其重要性。我可能需要修正视角来解决问题，或者我可能需要更深入地研究 EAV/CR。
喜欢 EAV/CR 模型的积极响应。我的开发同事们都说了 Jeffrey Kemp 在下面谈到的内容：“新实体必须由专业人士建模和设计”（断章取义，请阅读下面他的回复）。问题是：
- 实体每周添加和删除属性
（搜索关键词决定未来的属性）
- 每周都有新实体到达
（产品由零件组装而成）
- 旧实体每周消失
（已存档、不太受欢迎、季节性）
客户想要为产品添加属性有两个原因：
- 部门/关键词搜索/同类产品对比图
- 结账前消费产品配置
属性必须有意义，而不仅仅是关键词搜索。如果他们想比较所有具有“生奶油糖霜”的蛋糕，他们可以单击蛋糕，单击生日主题，单击生奶油糖霜，然后检查所有有趣的蛋糕，因为它们都具有生奶油糖霜。这不是特定于蛋糕，只是一个例子。
我能想到一些一般的优点和缺点，在某些情况下，其中一种比另一种更好：
选项 1，EAV 型号：
- 优点：设计和开发简单应用程序的时间更少
- 优点：很容易添加新实体（甚至可能
由用户添加？）
- Pro：“通用”界面组件
- 缺点：验证简单数据类型需要复杂的代码
- 缺点：简单的 SQL 更复杂
报告
- 缺点：复杂的报告几乎可以变得
不可能的
- 缺点：大型数据集性能较差
选项 2，分别对每个实体建模：
- 缺点：需要更多时间收集
要求和设计
- 缺点：必须对新实体进行建模并且
由专业人士设计
- 缺点：为每个组件自定义界面组件
实体
- 优点：数据类型约束和验证易于实现
- 优点：SQL 易于编写、易于实现
理解并调试
- 优点：即使是最复杂的报告也相对简单
- Pro：大型数据集的最佳性能
选项 3，组合（“正确”建模实体，但为某些/所有实体的自定义属性添加“扩展”）
- 优点/缺点：收集需求和设计所需的时间比选项 1 更多，但可能不如选项 2 *
- 缺点：新实体必须由专业人员建模和设计
- 优点：以后可以轻松添加新属性
- 缺点：验证简单数据类型需要复杂的代码（对于自定义属性）
- 缺点：仍然需要自定义界面组件，但通用界面组件可能适用于自定义属性
- 缺点：一旦报表中包含任何自定义属性，SQL 就会变得复杂
- 缺点：总体性能良好，除非您开始需要按自定义属性进行搜索或报告
* 我不确定选项 3 是否一定会节省设计阶段的时间。
就我个人而言，我倾向于选择 2，并尽可能避免 EAV。然而，对于某些场景，用户需要 EAV 带来的灵活性；但这需要付出巨大的代价。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
