为什么magento跨属性类型存储EAV数据？

Question

在magento系统中，有5个表可以跨属性类型存储EAV数据。这是一个有效的性能选择吗？当我进行SQL查询时，我仍然需要使用UNION子句来获取整个数据集。如果我使用一个混合表来根据唯一的数据类型（sql server2008中的varchar或sql_variant）存储EAV数据，将来我会遇到什么性能问题？

Answer 1

  

这样做是否是一种有效的表现选择？

Magento开发人员选择使用EAV结构，因为它在大量数据下表现良好。平台结构适用于小型设置，但随着它的扩展，它变得越来越低效。

  

当我进行sql查询时，我仍然需要使用UNION子句来获取整个数据集。

您应该尝试在每种可能的情况下避免在Magento数据库上进行直接SQL查询。它们具有可用于安装新数据的安装模型，您可以使用已存在的Magento模型以及安装模型创建/修改Magento核心配置数据或变量的方法，或使用基础Zend框架和＃39; s ORM如果你需要创建新表等等。

具体而言，就数据库的EAV部分而言，如果从SQL的角度对其进行攻击，它的设置方式会很复杂，这就是Magento模型存在的原因所以它可以全部用PHP包装ORM。如果可以的话，再次避免SQL查询。

如果您有进行直接查询，您将无法创建UNION查询但是加入这些表，并且您将eav_attribute表用作数据透视表，为您提供attribute_id（主键）和值将存在的源表。

通过使用直接SQL查询，您还会丢失Magento在商店或网站级别值存在的情况下实施的回退系统，如果您在商店级别要求它们，Magento模型将选择它们。如果要使用SQL手动执行此操作，则查询会变得更加复杂，因为您需要查找这些值，如果找不到这些值，则还原为默认（全局范围）值。

  

如果我使用一个混合表来根据唯一的数据类型（sql server2008中的varchar或sql_variant）存储EAV数据，将来我会遇到哪些性能问题？

如前所述，它取决于数据库的预期规模。您会注意到标准Magento数据库中有很多平面表，并且EAV结构仅适用于Magento开发人员决定可能会大幅增加的部分（客户，目录等）。

如果您想要实现一个自定义模块，并且您认为它也有可能随着时间的推移快速增长，那么您可以为它实现自己的EAV表。 Magento模型支架支持这一点，网上有大量关于如何设置它们的资源。

如果你的桌子可能保持（相对）小，那么一定要采用平桌方法。如果它是一个自定义模块，并且您注意到快速增长，那么您可以在它成为瓶颈之前随时将其转换。