| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Составление SQL-запросов > Запрос объеденяющий 3 таблицы MySQL |
| Автор: gribikc 18.9.2012, 15:43 | ||||
| Добрый день. пытаюсь создать каталог с фильтром на подобие того который на сайте http://www.citilink.ru/catalog/parts/cpu/. Сделал 3 таблицы
в таблице `filter` содержатся названия фильтров в таблице `params` содержатся параметры товаров и соответсвующего фильтра Помогите оптимизировать запрос всё что я смог придумать:
|
| Автор: Sanchezzz 18.9.2012, 21:14 | ||
|
| Автор: gribikc 18.9.2012, 21:43 | ||||
| нет не совсем мой запрос выводит
а этот
у сакуры объём 0.9 |
| Автор: Zloxa 19.9.2012, 09:59 |
Что вас не устраивает в том, что вы придумали? Добавлено через 3 минуты и 30 секунд индекс по паре params(f_val,id_fil) - единственное, что приходит в голову |
| Автор: gribikc 19.9.2012, 12:37 | ||||
то что для каждому фильтру надо будет добавлять следующие
|
| Автор: Zloxa 19.9.2012, 13:51 |
И чем именно это вас не удовлетворяет? Но так вобще... Походу вы сначала определили структуру, а потом задались вопросом, как по ней искать. Правильнее же было бы, мне кажется, для начала решить как должен производиться поиск, а потом под это решение готовить структуру. Если вам к предикатам отбора необходимо применять оператор И, структура с динамически определяемым пользователем набором атрибутов - определенно не самая рациональная. Чем вы можете обосновать необходимость динамического формирования атрибутов? Почему их нельзя разместить непосредственно в столбцах справочника товара? Полагаю ответ прост. Либо вы(возможно как и ваш заказчик) не знаете каков набор атрибутов будет определен для товара, когда продукт поступит в промышленную эксплуатацию. Либо готовите универсальное, гибкое решение на все случаи жизни. В первом случае это недостаток аналитической проработки, во втором случае - утопия. В обоих случаях - попытка сэкномить. А не рациональность - цена этой экономии. |
| Автор: gribikc 20.9.2012, 08:57 |
| Не удовлетворяет скорость работы этого дела. Да действительно сначало была определена структура. Ну а по поводу второго, да действительно делалось универсальное решение |
| Автор: Zloxa 20.9.2012, 09:31 | ||
Если требуется осущестлять поиск по диапазону id_fil (использовать для отбора операторы >,<, between), придется строить два индекса. Один для in - по паре (c_val,id_fil), один для exits по тройке (id_to,c_val,id_fil) |
| Автор: gribikc 1.12.2012, 22:27 | ||
нашел решение
с небольшой переделкой базы но суть таже |