Меню
Что нового?

Тяжело ли MySQL это обрабатывать?

Fru

Guest
Тяжело ли MySQL это обрабатывать?

Всем привет!
Есть запрос в БД следующего содержания:
SELECT * FROM shina WHERE (id=62 OR id=63 OR id=64 OR id=65 OR id=66 OR id=67 OR id=69 OR id=70 OR id=68 OR id=71 OR id=72 OR id=73 OR id=74 OR id=75 OR id=76 OR id=77 OR id=78 OR id=79 OR id=80 OR id=81 OR id=82 OR id=83 OR id=84 OR id=85 OR id=86 OR id=87 OR id=88 OR id=89 OR id=90 OR id=91 OR id=92 OR id=93 OR id=94 OR id=95 OR id=97 OR id=99 OR id=100 OR id=101 OR id=102 OR id=108 OR id=104 OR id=105 OR id=106 OR id=107 OR id=109 OR id=110 OR id=111 OR id=112 OR id=113 OR id=114 OR id=115 OR id=116 OR id=118 OR id=119 OR id=120 OR id=121) LIMIT 40,10;

Запрос ест-но формируется скриптом, в него вставляются id'шники моделей из той категории товаров, которые хочет видеть пользователь.
Этот запрос не несет серьезной нагрузки на БД? Потому что этих OR'ов может быть и сотня и тысяча, в зависимости от кол-ва товаров. Как можно его оптимизировать?
 

Fru

Guest
Ок, спасибо. Но, я так понимаю, что упрощенный синтаксис не меняет положения дел или для процессора SQL это уже легче?
 

Fru

Guest
Фанат
В том-то и дело, что как таковая категория в БД не прописана. Есть таблица с автомобильными шинами, которые делятся на зимние, летние и всесезонные. Зима, лето и всесезонка имеют свои номера: 0,1 и 2 соответственно, которые и записываются в столбец "sezon" для каждой строки модели.
И есть калькултор по которому можно отфильтровать ассортимент магазина, к примеру, вывести все зимние или летние шины. Вот и встала проблема. У меня скрипт бегает по БД, отсортировывает все по id'шнику сезона и полученный id'шник модели (если она подходит по критерию запроса сезона) пихает в следующий SQL запрос на получение типоразмеров шин.

Извините, что сложно изъясняюсь, просто не знаю как на пальцах объяснить эту схему...
 
Фанат

Фанат

oncle terrible
Команда форума
У меня скрипт бегает по БД, отсортировывает все по id'шнику сезона и полученный id'шник модели (если она подходит по критерию запроса сезона) пихает в следующий SQL запрос
Нажмите для раскрытия...
да, после такого спрашивать, не нагрузит ли запрос базу, это всё равно, что взорвать жилой дом, а потом интересоваться - не побеспокоил ли кого-нибудь шум от взрыва.
В том-то и дело, что как таковая категория в БД не прописана.
Нажмите для раскрытия...
как это - не прописана? а
"sezon"
Нажмите для раскрытия...
- это что такое?
 

Fru

Guest
уф...

Значит так,

есть ДВЕ таблицы. Первая:
----------------------------------------------------
| ID модели | Название модели | Сезон |
----------------------------------------------------

Вторая:
----------------------------------------------------
| ID модели | Типоразмер шины | Цена |
----------------------------------------------------

Типоразмеров у каждой модели шины много, поэтому пихать все в одну таблицу тоже не рационально, сами понимаете... Поэтому сделал две таблицы между которыми установлена связь один-к-одному по ключу "ID модели".
Вот мне и нужно аккуратно выбрать из БД те типоразмеры, которые относятся к определенному сезону.

Надеюсь, так понятней...
 
Фанат

Фанат

oncle terrible
Команда форума
Типоразмеров у каждой модели шины много
Нажмите для раскрытия...
если много, то это называется не один-к-одному
между которыми установлена связь один-к-одному по ключу "ID модели".
Нажмите для раскрытия...
НУ ТАК ИСПОЛЬЗУЙ ЭТУ СВЯЗЬ.
ты слышал что-нибудь об объединении таблиц?
 

Panchous

Павел
[sql]select s.id, f.name, s.type, s.price
from `первая` f, `втoрая` s
where f.id=s.id AND f.sezon in (1,2)[/sql]
 

Fru

Guest
нет. Видимо я что-то упустил. Где об этом можно почитать?
 
Фанат

Фанат

oncle terrible
Команда форума
Fru
читать можно в документации, или в книжке по SQL.
но в принципе, всё понятно и глядя на запрос Panchous-а
 
Войдите или зарегистрируйтесь для ответа.
Сверху