Te veel tafels; MySQL kan slechts 61 tabellen in een join gebruiken

U gebruikt een EAV-ontwerp en probeert een enkele rij te reconstrueren uit een variabel aantal attributen. Dit wijst op een van de vele landmijnen die je tegenkomt bij het gebruik van het EAV-ontwerp:er is een praktische limiet op het aantal joins dat je kunt doen in een enkele SQL-query.

Vooral in MySQL -- er is een harde limiet, zoals je hebt gevonden. Maar zelfs bij andere RDBMS-merken is er een effectieve limiet omdat de kosten van joins geometrisch zijn in verhouding tot het aantal tabellen.

Als u EAV gebruikt, probeer dan geen rij te reconstrueren in SQL alsof u een conventioneel databaseontwerp had. Haal in plaats daarvan de attributen op als rijen, gesorteerd op de entiteits-ID. Verwerk ze vervolgens in je sollicitatiecode. Dit betekent wel dat je de gegevens niet in één stap kunt dumpen -- je moet code schrijven om over de attribuutrijen te lopen, en elke rij met gegevens hervormen voordat je deze kunt uitvoeren.

EAV is geen handig databaseontwerp. Er zijn veel dure nadelen aan het gebruik ervan, en je hebt er net een geraakt.

Zie http://www.simple-talk.com/opinion /opinion-pieces/bad-carma/ voor een geweldig verhaal over hoe het gebruik van EAV een bedrijf heeft verdoemd.

En zie ook http://en.wikipedia.org/wiki/Inner-platform_effect omdat EAV een voorbeeld is van dit antipatroon.

Ik begrijp de noodzaak om een ​​dynamische set attributen per product in een catalogus te ondersteunen. Maar EAV gaat je applicatie doden. Dit is wat ik doe om dynamische kenmerken te ondersteunen:

• Definieer een echte kolom in de basistabel voor elk kenmerk dat voor alle producttypen geldt. Productnaam, prijs, hoeveelheid op voorraad, enz. Werk hard om het canonieke product voor te stellen entiteit, zodat u zoveel mogelijk attributen in deze set kunt opnemen.

• Definieer nog een kolom van het type TEXT voor alle aanvullende kenmerken van elk bepaald producttype. Opslaan in deze kolom als Geserialiseerde LOB van de attributen, in elk formaat dat bij u past:XML, JSON, YAML, uw eigen zelfgemaakte DSL, enz.

  Behandel dit als een enkele kolom in uw SQL-query's. Voor elke zoekopdracht, sortering of weergave op basis van deze kenmerken moet u de hele TEXT ophalen blob in uw applicatie deserialiseren en de attributen analyseren met behulp van applicatiecode.