我正在为电子商务应用程序设计我的数据库/域，但我很难弄清楚如何存储产品。
该网站将出售各种各样的产品，钢笔、丁字裤、纹身、雨伞，应有尽有。这些产品中的每一个都有一些共同的属性，高度、宽度、长度、重量等，但有些产品有特殊的数据。例如，钢笔有不同的墨水颜色， Nib /盖子和小册子可以有不同类型的折叠。到目前为止，我已经想到了大约 20 多个额外属性，但这些属性可能仅适用于网站上 1% 的产品。
所以我想知道是否适合实现 EAV 模型来处理额外数据。请记住，当客户在前端查看网站时，将会有一个过滤侧边栏，就像在 eBay 和 carsales.com.au 上一样。 (所以请记住，会有相当多的查询)
我认为实现类表继承并不实际，因为系统需要保持灵 active 。这是因为，在未来我们可能会通过新类型的产品获得更多属性。
我考虑过的另一件事是使用 NoSQL 数据库(可能是 MongoDB)，但是我对这些类型的数据库几乎没有经验，它甚至可以解决我的问题吗？
审查选项:
- 具有大量列的单个产品实体
- 单独的属性实体 (EAV)
- 切换到无模式持久性
我正在构建一个带有属性实体的原型(prototype)，以了解它的灵 active ，并测试性能以及查询的失控程度。
编辑:当然，我愿意接受任何其他解决方案。
最佳答案
很好的问题，但当然，没有“唯一正确的方法”。根据@BenV，Magento 确实使用 EAV 模型。我对它的体验非常积极，但它确实让其他用户感到不安。一些注意事项:
1.性能。 EAV 需要复杂的多表连接来使用相关属性填充您的对象。这确实会影响性能。但是，可以通过仔细缓存(通过堆栈的所有级别，包括查询缓存)和选择性使用非规范化来缓解这种情况。 Magento 确实允许管理员为 SKU 数量(通常为数千个)保证的类别和产品选择非规范化模型。这反过来需要观察者触发重新索引(总是很好!)并在产品数据更改时更新“平面”非规范化表。这也可以安排或手动触发，并提示管理员。
<强>2。第三方用户复杂性 如果您打算将此应用程序提供给其他用户，许多人会发现 EAV 过于复杂，并且您最终会在用户论坛上处理大量喋喋不休和不知情的滥用(引用 Magento !!)。
3. future 的可扩展性和插件架构。 毫无疑问，当可扩展性成为一个因素时，EAV 模型真正发挥作用。将新属性添加到模型中非常简单，同时将破坏现有 ORM 和 Controller 代码的风险降至最低。
4.数据类型的变化
EAV 确实使更改属性数据类型变得更加困难。如果您的初始设计需要将来更改的特定属性数据类型(例如 int 到 varchar)，则意味着您必须将该属性的所有记录迁移到与新数据类型匹配的对应表。当然，纯粹主义者会建议你在第一时间就做好设计，但现实有时会闯入!
5.手动产品导入 EAV 使几乎不可能的一件事是使用 SQL 和/或 phpMyAdmin 样式的 CSV/XML 将产品(或其他实体)导入数据库。您需要编写一个 Importer 模块，该模块接受结构化数据并将其传递到应用程序的模型层以将其持久保存到数据库中。这确实增加了您的复杂性。
关于php - 我应该使用 EAV 模型吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4066463/