Суть в том, что поисковый демон sphinx позволяет находить подстроки в поле быстрее, чем MySQL, а Вам нужно делать после каждого клика пользователя на фильтре столько запросов, сколько фильтров у Вас есть. Например:
в одной таблице хранятся "заголовки" фильтров:
1 | диагональ
2 | память
3 | ёмкость
во второй таблице - значения и указания на "заголовки":
1 | 1 | До4"
1 | 2 | 4.1" - 4.5"
...
2 | 1 | <1ГБ
... и т.д.
в третьей таблице (или в таблице товаров) хранятся значения этих фильтров для конкретных товаров:
666 | Телефон Самсунг... 4,3" 2гБ | 1_2 2_3 ...
667 | Телефон Самсунг... 6" 3гБ | 1_5 2_4 ...
и т.д.
Когда пользователь выбирает фильтр 2_4, то есть ы группе под заголовком "Оперативная память" значение 4 строки - "3ГБ", то фильтры перезагружаются - вы ищите в БД все записи товаров, у которых имеется выбранный фильтр 2_4 и:
фильтр 1_1,
затем фильтр 1_2 и т.д., тем самым, вычисляя количества товаров, которые могут быть выведены пользователю если он на следующем шаге выберет тот или иной фильтр. Если такое количество == 0, то фильтр стает неактивным.
А для фильтров из-под заголовка, под которым уже выбрано хотя бы одно значение, нужно вычислять, сколько товаров добавится к имеющемуся множеству если пользователь расширит свой выбор, выбрав ещё одно значение:
Далее для ускорения в сфинксе строится индекс на подобии такого:
где param_id - ID заголовка фильтра,
value_id - ID значения, а
filter - то самое поле из БД, по которому будут искаться выбранные фильтры:
SELECT param_id, value_id, COUNT(*) AS cnt
FROM filters
WHERE MATCH('@filter 1_3 2_4')
GROUP BY value_id
типо того... Но если Вы не используете этот поисковый демон в своём проекте, то песня может затянуться, с другой стороны, т.к. я других способов реализации не встречал, хотелось бы рассмотреть, как можно решить эту задачу иначе.
в одной таблице хранятся "заголовки" фильтров:
1 | диагональ
2 | память
3 | ёмкость
во второй таблице - значения и указания на "заголовки":
1 | 1 | До4"
1 | 2 | 4.1" - 4.5"
...
2 | 1 | <1ГБ
... и т.д.
в третьей таблице (или в таблице товаров) хранятся значения этих фильтров для конкретных товаров:
666 | Телефон Самсунг... 4,3" 2гБ | 1_2 2_3 ...
667 | Телефон Самсунг... 6" 3гБ | 1_5 2_4 ...
и т.д.
Когда пользователь выбирает фильтр 2_4, то есть ы группе под заголовком "Оперативная память" значение 4 строки - "3ГБ", то фильтры перезагружаются - вы ищите в БД все записи товаров, у которых имеется выбранный фильтр 2_4 и:
фильтр 1_1,
затем фильтр 1_2 и т.д., тем самым, вычисляя количества товаров, которые могут быть выведены пользователю если он на следующем шаге выберет тот или иной фильтр. Если такое количество == 0, то фильтр стает неактивным.
А для фильтров из-под заголовка, под которым уже выбрано хотя бы одно значение, нужно вычислять, сколько товаров добавится к имеющемуся множеству если пользователь расширит свой выбор, выбрав ещё одно значение:
Далее для ускорения в сфинксе строится индекс на подобии такого:
где param_id - ID заголовка фильтра,
value_id - ID значения, а
filter - то самое поле из БД, по которому будут искаться выбранные фильтры:
типо того... Но если Вы не используете этот поисковый демон в своём проекте, то песня может затянуться, с другой стороны, т.к. я других способов реализации не встречал, хотелось бы рассмотреть, как можно решить эту задачу иначе.