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