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

Question

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

​

​

Answer 1

这样做是一种有效的性能选择吗？

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

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

您应该在每一种可能的情况下尝试避免在Magento数据库上进行直接SQL查询。它们有可用于安装新数据的安装模型，其中要么使用已经存在的Magento模型，要么使用安装模型必须创建/修改Magento核心配置数据或变量的方法，或者在需要创建新表时使用基础Zend框架的ORM等。

具体来说，就数据库中的EAV部分而言，如果您从SQL角度攻击它，那么它的设置方式就很复杂，这就是Magento模型存在的原因，这样就可以将其全部封装在PHP中。同样，如果可以，请避免SQL查询。

如果必须进行直接查询，则不会创建UNION查询，而是将其连接到这些表上，您将使用eav_attribute表作为枢轴表，为您提供值将存在的attribute_id (主键)和源表。

通过使用直接SQL查询，您还会丢失Magento实现的备用系统，而Magento实现的存储或网站级别值可能存在，如果在存储级别上提出请求，Magento模型将选择它们。如果您希望使用SQL手动执行此操作，则查询变得更加复杂，因为您需要查找这些值，如果找不到这些值，则恢复到默认(全局范围)值。

如果我使用一个混合表根据唯一的一种数据类型(varchar，或sql server2008中的server2008)存储EAV数据，那么将来会遇到什么性能问题？

如前所述，这取决于数据库的预期规模。您将注意到标准Magento数据库中有大量的平面表，并且EAV结构只适用于Magento开发人员认为可能会大幅度增加的部件(客户、目录等)。

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

如果您的表可能保持(相对)小，那么无论如何都要采用平坦的表方法。如果它是一个自定义模块，并且您注意到它的快速增长，那么在它成为瓶颈之前，您可以在稍后转换它。