Você está certo de que unir muitos atributos por meio de um design EAV provavelmente excederá o limite de uniões. Mesmo antes disso, provavelmente há um limite prático de junções porque o custo de tantas junções fica cada vez mais alto geometricamente. O quão ruim isso é depende da capacidade do seu servidor, mas é provável que seja um pouco menor que 61.
Portanto, consultar um modelo de dados EAV para produzir um resultado como se estivesse armazenado em um modelo relacional convencional (uma coluna por atributo) é problemático.
Solução:não faça isso com uma junção por atributo, o que significa que você não pode esperar produzir o resultado em um formato convencional de linha por entidade puramente com SQL.
Não estou intimamente familiarizado com o esquema Magento, mas posso inferir da sua consulta que algo assim pode 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;
O
IN(2,3,4,...) predicado é onde você especifica vários atributos. Não há necessidade de adicionar mais junções para obter mais atributos. Eles são simplesmente retornados como linhas em vez de colunas. Isso significa que você precisa escrever o código do aplicativo para buscar todas as linhas desse conjunto de resultados e mapeá-las em campos de um único objeto.
A partir dos comentários de @Axel, parece que o Magento fornece funções auxiliares para fazer esse consumo de um conjunto de resultados e mapeá-lo em um objeto.
