Je hebt gelijk dat het samenvoegen van te veel attributen via een EAV-ontwerp waarschijnlijk de limiet van het aantal samenvoegingen zal overschrijden. Zelfs daarvoor is er waarschijnlijk een praktische limiet voor joins omdat de kosten van zoveel joins geometrisch steeds hoger worden. Hoe erg dit is, hangt af van de capaciteit van uw server, maar het is waarschijnlijk een stuk lager dan 61.
Dus het opvragen van een EAV-gegevensmodel om een resultaat te produceren alsof het in een conventioneel relationeel model is opgeslagen (één kolom per attribuut) is problematisch.
Oplossing:doe het niet met een join per attribuut, wat betekent dat je niet kunt verwachten dat je het resultaat in een conventioneel rij-per-entiteitsformaat puur met SQL produceert.
Ik ben niet goed bekend met het Magento-schema, maar ik kan uit uw vraag afleiden dat zoiets zou kunnen werken:
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;
De IN(2,3,4,...) predikaat is waar u meerdere attributen opgeeft. Het is niet nodig om meer joins toe te voegen om meer attributen te krijgen. Ze worden gewoon geretourneerd als rijen in plaats van kolommen.
Dit betekent dat je applicatiecode moet schrijven om alle rijen van deze resultatenset op te halen en ze toe te wijzen aan velden van een enkel object.
Uit opmerkingen van @Axel, klinkt het alsof Magento helperfuncties biedt om dit te doen door een resultatenset te consumeren en deze in een object in kaart te brengen.