Что быстрее 50 маленьких или 1, но большой запрос?

[REMO]

Что быстрее 50 маленьких или 1, но большой запрос?

Что лучше с точки зрения снижения нагрузки на БД, что будет быстрее и т.д.?

Насколько мне известно нагрузку на БД создает не только количество запросов, но и их величина (т.е. размер передаваемой информации в запросе).

Отсюда возникает вопрос. Что лучше? В цикле сделать 50 запросов размер которых будет меньше (но их будет 50, а может и 150-200), или сделать 1 большой запрос в каждой строке которого будет повторяться много ненужных данных. Что как я понимаю увеличит размер запроса и негативно скажется на скорости работы и загрузке БД.

 

[Demiurg]

тестируй.
У тебя на каждой странице по 50 запросов ?

 

[Falc]

REMO
1 большой, если он не кривой, лучше.

>>в каждой строке которого будет повторяться много ненужных данных.

Что значит много ненужных данных?
Ненужные данные не нужно и выбирать.

 

[HEm]

Для каждой задачи свой запрос
если у тебя новости, статьи и, скажем, акции в одной таблице и тебе нужно в разные участки страницы вставить блоки по каждому виду статей, то проще со всех точек зрения сделать три разных простых запроса, чем придумывать какой-то сложный запрос, чтобы вытащить все сразу

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

 

[Falc]

>>новости, статьи и, скажем, акции в одной таблице и тебе нужно в разные участки страницы вставить блоки по каждому виду статей

Такое в цикле обычно не делают.

 

[Tigr]

Первым делом, нужно правильно задачу себе представлять и уметь составлять запросы и оптимизировать их, дорога к этому лежит во времени и http://dev.mysql.com/doc/mysql/ru/index.html

а, дальше ..., повторю Demiurg-а - тестируй.

 

[REMO]

Представлю задачу более подробно.

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

Если делать одним запросом, то количество строк в запросе будет равно количеству товаров * на количество свойств второй таблицы (т.е. до 20). В запросе возникнет много не ненужных, а повторных (я не правильно выразился) данных. Т.е. размер(веса) запроса значительно возрастет... Но это будет один запрос.

С другой стороны мы можем сделать для каждой позиции товара еще один запрос на его свойства (отсюда как раз и вылазит +50 запросов). И тогда избежим увеличения размера(веса) запроса. Но в будещем предвидется увеличение количества товаров до 150 (150 запросов в часто исполняемом скрипте это не слишком)?

Т.е. по сути я хочу понять. Стоит ли ориентироваться в первую очередь на количество запросов или на их вес? Учитывая, что сайт хостится на виртуальном сервере и ресурсы сервера для сайта ограничены.

тестируй.
У тебя на каждой странице по 50 запросов ?

Эта страница в основном и подвергается использованию. Т.е. скрипт исполнятеся достаточно часто.

Насчет тестировать. А как тестировать нагрузку на БД? Скорость запроса я могу померить. Хотя в принципе я так понимаю, что это вещи взаимосвязанные. Чем меньше скорость, тем меньше нагрузка.

 

[Demiurg]

соеденение 2 простых табличек - это не сложная задача, а вот 50 запросов - это 50 не сложных задач. Ты беспокоишся о количестве данных возвращаемых запросом или о сложности запроса ?

 

[Falc]

REMO
Я уже написал, но повторюсь. один запрос лучше.

 

[REMO]

соеденение 2 простых табличек - это не сложная задача, а вот 50 запросов - это 50 не сложных задач. Ты беспокоишся о количестве данных возвращаемых запросом или о сложности запроса ?

Сложность запроса меня не беспокоит. Один раз написал гуляй свободным. Конечно меня волнует количество данных возвращаемых запросом.

К примеру, в таблице перечня товаров содержится описание товара. Т.е. если мы делаем один запрос. То получается, что мы это описание товара умножаем на 20. И так 50 раз.

Я уже написал, но повторюсь. один запрос лучше.

Я тоже так думаю, но у меня есть сомнения, которые описаны выше А можешь объяснить почему один лучше?

 

[Demiurg]

Ты то один раз написал, а серверу каждый раз выполнять, я про сложность для субд.

 

[Falc]

REMO
>>А можешь объяснить почему один лучше?
Потому что даже при простом запросе уходит много времени на посылку запроса и его парсинг.

 

[REMO]

Автор оригинала: Falc
REMO
>>А можешь объяснить почему один лучше?
Потому что даже при простом запросе уходит много времени на посылку запроса и его парсинг.

Но все ведь относительно. Может времени больше уйдет на передачу повторяющихся данных? Или по любому нет...

 

[Falc]

REMO
Если повторяющихся данных действительно так много, что их переда тормозит, то можно сделать 2-мя запросами.

 

[REMO]

Автор оригинала: Falc
REMO
Если повторяющихся данных действительно так много, что их переда тормозит, то можно сделать 2-мя запросами.

Т.е. двумя вообще или второй ставить в цикл (тогда получится 50)?

 

[Falc]

REMO
Двумя вообще

 

[REMO]

Автор оригинала: Falc
REMO
Двумя вообще

Тогда придется изголяться с выводом, т.к. придется обрабатывать массив результата.

Т.е. я так понимаю это лучше все таки с результатом повозится в ПХП, чем мускул 50 раз напрягать. Так?

-~{}~ 01.06.04 16:36:

Вообще я так прикинул, что то получается несуразное. Как мне сделать это в два запроса всего, намекни хотя бы...

-~{}~ 01.06.04 16:38:

А есть какая то функция которая считает количество запросов произведенных скриптом. Думаю, что нет конечно, но так на всякий случай

 

[Falc]

REMO
>>А есть какая то функция которая считает количество запросов произведенных скриптом.

Можно самому подсчитать.


>>Как мне сделать это в два запроса всего, намекни хотя бы...

Одним запросом, вытаскиваешь данные о товарах.
Вторым запросом их свойства ("повторными" данными будет только id товара).

 

[REMO]

Автор оригинала: Falc
REMO
>>Как мне сделать это в два запроса всего, намекни хотя бы...

Одним запросом, вытаскиваешь данные о товарах.
Вторым запросом их свойства ("повторными" данными будет только id товара).

ОК понял. А как тогда сделать следующее. К примеру я вытаскиваю перечень товаров с ORDER BY RAND (число)...

Мне же надо, чтобы второй запрос был синхронным как бы.

Т.е. ID первого результата запроса: 101, 102, 103...
ID второго результата запроса: 101, ..., 101, 102, ..., 102 ......

Как сделать так чтобы порядок строк в запросах соответствовал.

Просто ORDER BY RAND (число) во втором запросе не помогает... хотя я так понимаю и не должно.

 

[Falc]

REMO
А зачем тебе сохранять порядок?
Связывай по ID через массивы.