Sie haben Recht, dass das Verbinden zu vieler Attribute durch ein EAV-Design wahrscheinlich die Grenze der Verbindungen überschreitet. Selbst davor gibt es wahrscheinlich eine praktische Grenze für Joins, da die Kosten für so viele Joins geometrisch immer höher werden. Wie stark dies ist, hängt von der Kapazität Ihres Servers ab, aber es ist wahrscheinlich, dass sie etwas niedriger als 61 ist.
Daher ist es problematisch, ein EAV-Datenmodell abzufragen, um ein Ergebnis zu erhalten, als ob es in einem herkömmlichen relationalen Modell (eine Spalte pro Attribut) gespeichert wäre.
Lösung:Machen Sie es nicht mit einem Join pro Attribut, was bedeutet, dass Sie nicht erwarten können, das Ergebnis in einem herkömmlichen Zeilen-pro-Entität-Format nur mit SQL zu erzeugen.
Ich bin mit dem Magento-Schema nicht genau vertraut, aber ich kann aus Ihrer Anfrage schließen, dass so etwas funktionieren könnte:
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;
Der IN(2,3,4,...) Beim Prädikat geben Sie mehrere Attribute an. Es müssen keine weiteren Joins hinzugefügt werden, um mehr Attribute zu erhalten. Sie werden einfach als Zeilen und nicht als Spalten zurückgegeben.
Das bedeutet, dass Sie Anwendungscode schreiben müssen, um alle Zeilen dieser Ergebnismenge abzurufen und sie Feldern eines einzelnen Objekts zuzuordnen.
Aus Kommentaren von @Axel klingt es so, als ob Magento Hilfsfunktionen bereitstellt, um diese Ergebnismenge zu verbrauchen und sie einem Objekt zuzuordnen.
