Masz rację, że łączenie zbyt wielu atrybutów za pomocą projektu EAV prawdopodobnie przekroczy limit łączeń. Nawet wcześniej prawdopodobnie istnieje praktyczna granica złączeń, ponieważ koszt tak wielu złączeń jest coraz wyższy geometrycznie. Jak bardzo to jest złe, zależy od pojemności twojego serwera, ale prawdopodobnie będzie nieco niższa niż 61.
Zatem odpytywanie modelu danych EAV w celu uzyskania wyniku tak, jakby był przechowywany w konwencjonalnym modelu relacyjnym (jedna kolumna na atrybut), jest problematyczne.
Rozwiązanie:nie rób tego z łączeniem na atrybut, co oznacza, że nie możesz oczekiwać, że uzyskasz wynik w konwencjonalnym formacie wiersz na jednostkę wyłącznie za pomocą SQL.
Nie znam dokładnie schematu Magento, ale z Twojego zapytania mogę wywnioskować, że coś takiego może zadziałać:
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,...) predykat to miejsce, w którym określasz wiele atrybutów. Nie ma potrzeby dodawania kolejnych złączeń, aby uzyskać więcej atrybutów. Są one po prostu zwracane jako wiersze, a nie kolumny.
Oznacza to, że musisz napisać kod aplikacji, aby pobrać wszystkie wiersze tego zestawu wyników i odwzorować je na pola pojedynczego obiektu.
Z komentarzy @Axel wynika, że Magento zapewnia funkcje pomocnicze, które pochłaniają zestaw wyników i mapują go na obiekt.
