很好的问题，但是当然，没有“一个真正的方法”。根据@
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层传递，以将其持久化到数据库中。这确实增加了您的复杂性。
