Trop de tables ; MySQL ne peut utiliser que 61 tables dans une jointure

Vous utilisez une conception EAV et essayez de reconstruire une seule ligne à partir d'un nombre variable d'attributs. Cela met en évidence l'une des nombreuses mines terrestres que vous rencontrerez en utilisant la conception EAV :il existe une limite pratique au nombre de jointures que vous pouvez effectuer dans une seule requête SQL.

Surtout dans MySQL - il y a une limite stricte, comme vous l'avez constaté. Mais même dans d'autres marques de SGBDR, il existe une limite effective car le coût des jointures est géométrique par rapport au nombre de tables.

Si vous utilisez EAV, n'essayez pas de reconstruire une ligne en SQL comme si vous aviez une conception de base de données conventionnelle. Au lieu de cela, récupérez les attributs sous forme de lignes, triées par l'identifiant de l'entité. Ensuite, post-traitez-les dans votre code d'application. Cela signifie que vous ne pouvez pas vider les données en une seule étape - vous devez écrire du code pour boucler sur les lignes d'attributs et reformer chaque ligne de données avant de pouvoir les sortir.

EAV n'est pas une conception de base de données pratique. Son utilisation présente de nombreux inconvénients coûteux, et vous venez d'en rencontrer un.

Voir http://www.simple-talk.com/opinion /articles-d'opinion/bad-carma/ pour une belle histoire sur la façon dont l'utilisation d'EAV a condamné une entreprise.

Et voir aussi http://en.wikipedia.org/wiki/Inner-platform_effect car EAV est un exemple de cet anti-modèle.

Je comprends la nécessité de prendre en charge un ensemble dynamique d'attributs par produit dans un catalogue. Mais EAV va tuer votre application. Voici ce que je fais pour prendre en charge les attributs dynamiques :

• Définissez une colonne réelle dans la table de base pour chaque attribut commun à tous les types de produits. Nom du produit, prix, quantité en stock, etc. Travaillez dur pour imaginer le produit canonique entité afin que vous puissiez inclure autant d'attributs que possible dans cet ensemble.

• Définissez une autre colonne de type TEXT pour tous les attributs supplémentaires de chaque type de produit donné. Stocker dans cette colonne en tant que LOB sérialisé des attributs, dans le format qui vous convient :XML, JSON, YAML, votre propre DSL maison, etc.

  Traitez cela comme une seule colonne dans vos requêtes SQL. Toute recherche, tri ou affichage que vous devez effectuer en fonction de ces attributs nécessite que vous récupériez l'intégralité du TEXT blob dans votre application, désérialisez-la et analysez les attributs à l'aide du code de l'application.