Я знаю, даже знаю для чего она. Только нормализация таким способом приведет к возрастанию нагрузки, возрастание на поиск, потому что запрос будут очень сложными. Чем сложнее запрос, тем он медленнее.. а кэшировать всю базу нету смысла. Вот к примеру как построена база у яндекс маркета? Однозначно это eav, но у них нету такой проблемы, как не все заполнены поля..
Может есть какие-то другие варианты хранения ?
Думаю что надо просто создать одну базу для поиска, а вторую для простого показа.
В первой хранить значения с индексом, во второй простую статистику в виде json, которая формируется из ходя из заполненных полей..
Получается что база для поиска будет вот так выглядеть:
searche_$class_cat id|name|prince|param 1|param2|param 3| param4|all
searche_$class_cat_all id|param 9|param10|param 11|.. |param25
и база для вывода
product id|name|prince|param_json|итд..
Не, это подошло бы, если было 4 параметра и все они заполнялись.... а не от 25 параметров которые могут быть не заполнены.. Думаю что вообще в массиве хранить для простого вывода, а для поиска сделать единую базу со всеми параметрами и ключом на тот или иной объект "товар в нашел случаи" Не знаю только как избавить от пустых полей.. они будут тормозить базу
Не чего нового к увы..
eav используется во 2м и 3м варианте, да и в 1м тоже, но это не решение..
Что бы избавиться от null или пустого поля придется создать 625 вариаций, это еще хуже чем незаполненные ячейки.
Может есть какие-то другие варианты хранения ?
Думаю что надо просто создать одну базу для поиска, а вторую для простого показа.
В первой хранить значения с индексом, во второй простую статистику в виде json, которая формируется из ходя из заполненных полей..
Получается что база для поиска будет вот так выглядеть:
searche_$class_cat
id|name|prince|param 1|param2|param 3| param4|allsearche_$class_cat_all
id|param 9|param10|param 11|.. |param25и база для вывода
product
id|name|prince|param_json|итд..