Твърде много маси; MySQL може да използва само 61 таблици в обединение

Използвате дизайн на EAV и се опитвате да преконструирате един ред от променлив брой атрибути. Това посочва една от многото противопехотни мини, които ще срещнете, използвайки дизайна на EAV:има практическо ограничение за броя на присъединяванията, които можете да направите в една SQL заявка.

Особено в MySQL - има твърдо ограничение, както открихте. Но дори и в други марки RDBMS има ефективно ограничение, тъй като цената на обединяването е геометрична по отношение на броя на таблиците.

Ако използвате EAV, не се опитвайте да конструирате отново ред в SQL сякаш имате конвенционален дизайн на база данни. Вместо това извлечете атрибутите като редове, сортирани по идентификатора на обекта. След това ги обработете след това в кода на приложението си. Това означава, че не можете да изхвърлите данните в една стъпка – трябва да напишете код, за да обиколите редовете с атрибути и да реформирате всеки ред данни, преди да можете да ги изведете.

EAV не е удобен дизайн на база данни. Използването му има много скъпи недостатъци и току-що сте уцелили един от тях.

Вижте http://www.simple-talk.com/opinion /opinion-pieces/bad-carma/ за страхотна история за това как използването на EAV обрича един бизнес.

И също вижте http://en.wikipedia.org/wiki/Inner-platform_effect защото EAV е пример за този анти-шаблон.

Разбирам необходимостта от поддържане на динамичен набор от атрибути на продукт в каталог. Но EAV ще убие приложението ви. Ето какво правя, за да поддържам динамични атрибути:

• Дефинирайте реална колона в основната таблица за всеки атрибут, който е общ за всички типове продукти. Име на продукта, цена, количество на склад и т.н. Работете усилено, за да си представите каноничния продукт обект, така че можете да включите възможно най-много атрибути в този набор.

• Дефинирайте още една колона от тип TEXT за всички допълнителни атрибути на всеки даден тип продукт. Съхранявайте в тази колона като Сериализиран LOB от атрибутите, в какъвто формат ви подхожда:XML, JSON, YAML, собствен домашен DSL и т.н.

  Третирайте това като една колона във вашите SQL заявки. Всяко търсене, сортиране или показване, което трябва да направите въз основа на тези атрибути, изисква да извлечете целия TEXT blob във вашето приложение, десериализирайте го и анализирайте атрибутите с помощта на код на приложението.