Du har rätt i att en sammanfogning av för många attribut genom en EAV-design sannolikt kommer att överskrida gränsen för sammanfogningar. Redan innan dess finns det förmodligen en praktisk gräns för sammanfogningar eftersom kostnaden för så många sammanfogningar blir högre och högre geometriskt. Hur illa det här är beror på din servers kapacitet, men den kommer troligen att vara ganska lite lägre än 61.
Så att fråga en EAV-datamodell för att producera ett resultat som om den vore lagrad i en konventionell relationsmodell (en kolumn per attribut) är problematiskt.
Lösning:gör det inte med en join per attribut, vilket betyder att du inte kan förvänta dig att producera resultatet i ett konventionellt rad-per-enhet-format enbart med SQL.
Jag är inte så bekant med Magento-schemat, men jag kan dra slutsatsen från din fråga att något sådant här kan fungera:
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;
IN(2,3,4,...) predikat är där du anger flera attribut. Det finns inget behov av att lägga till fler kopplingar för att få fler attribut. De returneras helt enkelt som rader snarare än kolumner.
Det betyder att du måste skriva applikationskod för att hämta alla rader i denna resultatuppsättning och mappa dem till fält för ett enda objekt.
Från kommentarer av @Axel, låter det som att Magento tillhandahåller hjälpfunktioner för att göra detta genom att konsumera en resultatuppsättning och mappa den till ett objekt.