Интернет-магазин: стопор с архитектурой таблицы с товарами (для разных требуются разные поля)

[WebPHPDev]

Подскажите пожалуйста, каким образом реализуют такую структуру таблиц. У меня интернет-магазин, разные категории товаров, но у разных категорий товаров и разное количество полей (у одних товаров одни параметры, у других другие). Я создал отдельные таблицы отдельным категориям товаров. Хочется иметь возможность анализировать отдельно эти параметры (в частности поиск по отдельным критериям/полям), почему я и выделил в отдельные таблицы.

Всё бы ничего, если не поиск по всем товарам. Они ведь все в разных таблицах, проходить по каждой и искать, создавая кучу запросов при этом? Не лучшее решение

Так как же поступают в таких случаях разработчики?

 

[WebPHPDev]

Если сбагрить все товары в одну таблицу, где создать поле что-то вроде: additional_parameters (дополнительные поля/параметры товара), можно туда какое-то такое значение ставить, к примеру: "HDD=2Gb, Monitor=SamsungNNN". Если искать по этому полю текст - я ещё представляю, но как здесь анализировать критерий поиска пользователя типа такого: найти компьютеры с винтом от 1гб до 2гб, то вот тут уже не представляю, кроме как извлекать каждый товар, парсить, проверять... но не дело ведь это.

 

[Фанат]

Раньше так и делали.
Сейчас есть noSQL решения, в частности MongoDB,которая как раз подходит для таких случаев.

 

[WebPHPDev]

Раньше так и делали.

это как именно имеется ввиду?

 

[WebPHPDev]

В качестве возможного варианта, можно создать отдельную таблицу характеристик, типа такой:

id
product_id
param_key - имя дополнительной характеристики
param_value - её значение

Но такое тоже может начать притормаживать, если начнёшь связывать с таблицей товарой и выполнять, например, сортировку. Минус тут такой, что на каждый товар с дополнительными 10-30 характеристиками, прийдётся добавлять в эту таблицу 10-30 значений! Для каждого товара! А при сортировке сколько работы MySQL'ю прийдётся вытворить - жуть просто. Интересно, как это реализовано, например у Озона. Никто не знает?

Поэтому чёрт его знает, что же лучше (при использовании бд MySQL) - вот такое решение или создавать кучу таблиц на свои типы продуктов и искать в каждой из них, проходя все.

 

[С.]

Отдельная таблица характеристик вполне себе рабочий вариант. И работы в нем MySQL'ю прийдётся вытворять ни чуть не больше, чем со множеством категорийных таблиц.

 

[WebPHPDev]

Отдельная таблица характеристик вполне себе рабочий вариант. И работы в нем MySQL'ю прийдётся вытворять ни чуть не больше, чем со множеством категорийных таблиц.

Не понимаю, пока что, почему. В случае с отдельной таблицей характеристик прийдётся по каждому продукту (из таблицы продуктов) лазить в таблицу характеристик. А в случае с отдельными таблицами категорий - нам лазить никуда не прийдётся (если идентификаторы категорий держать (закэшенными) в массиве).

 

[С.]

Ну так закэшь и характеристики в этот же массив. Один дополнительный запрос еще никогда не убивал базу.

К тому же это операция извлечения товара, а ранее ты говорил о поиске.

 

[Absinthe]

Я бы предложил нормализовать предложенную выше схему:
products: id, .....
params: id, name, ....
id, product_id, param_id, param_value

 

[HEm]

Поищите по форуму, тема обсуждалась многократно

 

[Redjik]

Приходилось допиливать модекс, там все имеенно так и устроено, таблица с дополнительными параметрами, делал в цикле join ы всех дополнительных полей, все работало очень неплохо, единственное, немного запарно было с CAST значений к integer

 

[rotoZOOM]

Я бы предложил нормализовать предложенную выше схему:
products: id, .....
params: id, name, ....
id, product_id, param_id, param_value

В проекте сделал именно так.
Из минусов - если использовать фильтрацию/сортировку по параметрам, то будут тормоза, так как на третью таблицу индекс на param_value не составить.

 

[fixxxer]

Фильтрацию/сортировку по параметрам вообще на mysql-е делать не стоит при сколь-либо серьезных нагрузках и объемах базы. Тут nosql-и куда лучше подходят.

 

[zerkms]

В гугл по ключевому слову EAV

 

[computerworks]

Что-то мне подсказывает, что можно (и нужно) обойтись одной таблицей для всех товаров. В таблицу товаров добавить все существующие поля, и в случае отсутствия данных для некоторых полей у некоторых категорий товаров, просто оставлять пустыми.

 

[HEm]

computerworks
идем на яндекс-маркет например, смотрим по разным категориям, какие поля есть, и утирая слезы, добавляем в таблицу 100500 полей, из которых 100500-5 у каждой записи останутся пустыми....

 

[prolis]

Если вернутся к вопросу ТС

Я создал отдельные таблицы отдельным категориям товаров.
Хочется иметь возможность анализировать отдельно эти параметры (в частности поиск по отдельным критериям/полям), почему я и выделил в отдельные таблицы.
Всё бы ничего, если не поиск по всем товарам. Они ведь все в разных таблицах, проходить по каждой и искать, создавая кучу запросов при этом?

-проблемы с хранением данных нет - все группы товаров в своих таблицах (вполне логичное решение для ограниченного количества групп товаров)
-проблема с поиском товаров (я предполагаю по названию) - если решение с UNION не подходит, то нужно создать отдельную поисковую таблицу
-поиск и сравнение товаров в своих группах легок и непринужден
-если проблема с поиском сферических коней в вакууме (все товары массой 100г за 100р), то сначала EAV, а потом переосмыслить задачу до приведения её к предыдущим пунктам

 

[Beavis]

http://phpclub.ru/talk/threads/Универсальный-каталог.45567/

 

[scorpion-ds]

Я уже поднимал тут такой вопрос, и в своей задачи решил так:
В основной таблице, общие для всех полей значения, и таблица параметров с различными для разных категорий полями, но хранятся они все вместе, просто на вывод я запрашиваю только те, значения, что мне нужны для данного товара. Есть третья таблица, в ней хранится описание дополнительных полей (название, тип, сортировка (последовательность вывода) и т.п.) но при запросах на эта третья таблица не используется, она запрашивается всего раз, после чего кешируется ее значения и используются только для вывода (для пользователя).

Конечно это грубое объяснение, но у меня работает так.

 

[scorpion-ds]

Я бы предложил нормализовать предложенную выше схему:
products: id, .....
params: id, name, ....
id, product_id, param_id, param_value

Пробовал так, на первый взгляд самый очевидный вариант, но сильно притормаживает.