Hai ragione sul fatto che è probabile che l'unione di troppi attributi attraverso un design EAV superi il limite di join. Anche prima, c'è probabilmente un limite pratico di join perché il costo di così tanti join aumenta geometricamente. Quanto sia grave dipende dalla capacità del tuo server, ma è probabile che sia un po' inferiore a 61.
Pertanto, è problematico interrogare un modello di dati EAV per produrre un risultato come se fosse archiviato in un modello relazionale convenzionale (una colonna per attributo).
Soluzione:non farlo con un join per attributo, il che significa che non puoi aspettarti di produrre il risultato in un formato riga per entità convenzionale esclusivamente con SQL.
Non ho molta familiarità con lo schema Magento, ma posso dedurre dalla tua domanda che qualcosa del genere potrebbe funzionare:
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;
Il IN(2,3,4,...) predicato è dove specifichi più attributi. Non è necessario aggiungere più join per ottenere più attributi. Vengono semplicemente restituiti come righe anziché come colonne.
Ciò significa che devi scrivere il codice dell'applicazione per recuperare tutte le righe di questo set di risultati e mapparle nei campi di un singolo oggetto.
Dai commenti di @Axel, sembra che Magento fornisca funzioni di supporto per farlo consumando un set di risultati e mappandolo in un oggetto.
