Tiene razón en que es probable que unir demasiados atributos a través de un diseño de EAV exceda el límite de uniones. Incluso antes de eso, probablemente haya un límite práctico de uniones porque el costo de tantas uniones aumenta geométricamente. La gravedad de esto depende de la capacidad de su servidor, pero es probable que sea bastante inferior a 61.
Por lo tanto, consultar un modelo de datos EAV para producir un resultado como si estuviera almacenado en un modelo relacional convencional (una columna por atributo) es problemático.
Solución:no lo haga con una unión por atributo, lo que significa que no puede esperar producir el resultado en un formato convencional de fila por entidad únicamente con SQL.
No estoy íntimamente familiarizado con el esquema de Magento, pero puedo inferir de su consulta que algo como esto podría funcionar:
SELECT cpe.entity_id
, o.value AS option
, v.value AS option_value
FROM catalog_product_entity AS cpe
INNER JOIN catalog_product_entity_int AS i
ON cpe.entity_id = i.entity_id AND i.attribute_id IN (2,3,4)
INNER JOIN eav_attribute_option AS o
ON i.value = o.option_id AND i.attribute_id = o.attribute_id
INNER JOIN eav_attribute_option_value AS v
ON v.option_id = o.option_id;
El IN(2,3,4,...) predicado es donde se especifican múltiples atributos. No es necesario agregar más uniones para obtener más atributos. Simplemente se devuelven como filas en lugar de columnas.
Esto significa que debe escribir el código de la aplicación para obtener todas las filas de este conjunto de resultados y asignarlas a los campos de un solo objeto.
De los comentarios de @Axel, parece que Magento proporciona funciones de ayuda para consumir un conjunto de resultados y mapearlo en un objeto.
