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

REMO

Guest
Автор оригинала: Falc
REMO
А зачем тебе сохранять порядок?
Связывай по ID через массивы.
Т.е. сначала засунуть результат вторго запроса в ассоциативный массив. А потом к нему обращаться?

А не потеряются ли от этого выгоды, получаемые при сокращении количества запросов?

Т.е. мы убираем 40 запросов, оставляем 1. Но при этом создаем процедуру формирования ассоциативного массива. Элементами которго будут так же массивы, в которых будут лежать как раз свойства...

Я правильно улавливаю идею? Или ты что то другое имел ввиду?
 

Falc

Новичок
REMO
>>правильно улавливаю идею? Или ты что то другое имел ввиду?
Примерно, так.

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

REMO

Guest
Автор оригинала: Falc
REMO
>>правильно улавливаю идею? Или ты что то другое имел ввиду?
Примерно, так.

Но это относится к тому случаю если одним запросом сильно тормозит. Т.к. одним запросом это делается гораздо проще и во многих случаях быстрее.
Т.е. ты на самом деле не делал сам так никогда?

Ну как сильно тормозит. Я не мерил... :(

Я поэтому и пришел спросить на форуме, что лучше...

Ну если в результате запроса будет 10 строк и в каждой текст в 300 символов повторяющийся. И это помножить на количество товаров. Т.е. 10*50=500 строк с такими текстами. Вроде ясно, что ерунда полная... И быстрее будет работать 50 запросов....

А вот что быстрее 50-ти запросов, это вопрос :)
 

Falc

Новичок
REMO
>>Вроде ясно, что ерунда полная... И быстрее будет работать 50 запросов....
Не знаю почему тебе все так ясно.
Я например скланяюсь к обратному.
 

REMO

Guest
Автор оригинала: Falc
REMO
>>Вроде ясно, что ерунда полная... И быстрее будет работать 50 запросов....
Не знаю почему тебе все так ясно.
Я например скланяюсь к обратному.
Как учат ветераны клуба :) Скорость и нагрузка зависит не только от количества запросов, но и от их веса, так?

НУ вроде ясно, что тут вес будет немеренный... Из этого я и делаю вывод, что 50 в таком случае будет быстрее.

Рассудите нас...
 

Falc

Новичок
REMO
Ты тут уже второй день рассуждаешь, вместо того чтобы взять и проверить.

Тебе говорю что один запрос будет быстрее, если не верешь проверь в чем проблема?
 

Larson

Новичок
REMO, если ты не можешь даже приблизительно оценить затраты при выполнении различных вариантов реализации, то возьми сделай эти варианты и посмотри на конкретном примере. На вопрос, что быстрее один большой или 50 маленьких тебе здесь никто не ответит, т.к. это твой частный случай.
Что быстрее Белаз или Феррари? А если их нагрузить по 50 тонн? (с).

А по поводу какой-то лишней информации ты что-то гонишь.
У тебя есть набор данных, не важно в одной таблице или нескольких, который тебе необходимо получить. Какая разница чем ты будешь их выгребать - совком или лопатой - это вопрос производительности, а не объема.
Так что может быть тебе стоит пересмотреть структуру БД или сами запросы.
 

REMO

Guest
Только что провел эксперемент на локальной тачке... Если я все правильно сделал. ЕСЛИ...

В базе на локалке забито 15 наименований товара. Разница в скорости в пользу 50 запросов. При формировании массива скорость выполнения скрипта 0,5 сек. При 15 лишних запросах скорость 0,09-0,13.

Так что можно смело сделать вывод, что массивы идея не очень хорошая.

ХОТЯ. С другой стороны если мы будем использовать массивы, мы снизим нагрузку на БД. Что есть хорошо.

Опять диллема что выбрать?
 

Falc

Новичок
REMO
>>0,5 сек

Очень подозрительный резултат.
Обычно запросы работают гораздо быстрее например 0.005с
 

REMO

Guest
Автор оригинала: Larson
А по поводу какой-то лишней информации ты что-то гонишь.
У тебя есть набор данных, не важно в одной таблице или нескольких, который тебе необходимо получить. Какая разница чем ты будешь их выгребать - совком или лопатой - это вопрос производительности, а не объема.
Так что может быть тебе стоит пересмотреть структуру БД или сами запросы.
Согласен :) Но можно же выгребать по разному. К примеру с индексами или нет (неудачный пример, но тем не менее).

Структуру БД можно пересмотреть. Но что это даст? Ведь как не располагай данные если в одной из таблиц скажем 20 строк свойств. То в каждой строке результата будет весеть текст (описание товара).

Пример:

table1 id | name | desc
teble2 id | property

Если в таблице 2, 20 свойств товара из первой таблицы, то в массиве результата запроса будет, если мы вытащим инфу об одном товаре. 20 строк. В каждой из которых будет сидеть это текствое описание. 300 символов умножаем на 20, получаем что вес запроса сильно увеличился....

А если товар не один, а 50, получает вес запроса растет в геометрической прогресии.

Я не прав в чем то? И как тогда перестроить структуру, чтобы избедать увеличения веса?

-~{}~ 01.06.04 18:47:

2Falc

0,5 - это скорость работы скрипта..
 

Falc

Новичок
REMO
Насколько я понял скрипт состоит из одного запроса?
Если нет тогда вообще непонятно что ты мерял?

-~{}~ 01.06.04 18:52:

>>И как тогда перестроить структуру, чтобы избедать увеличения веса?

Пока ты не привел свою структуру, врядли можно что-то посоветовать.
 

Larson

Новичок
Блин, у тебя каждый товар имеет 10 свойств. Есть десять 10 товаров. Итого всего 100 свойств у 10 товаров. Хоть по одному ты их выгребай, а количество свойств не увеличется и не уменьшится.
 

REMO

Guest
Автор оригинала: Larson
Блин, у тебя каждый товар имеет 10 свойств. Есть десять 10 товаров. Итого всего 100 свойств у 10 товаров. Хоть по одному ты их выгребай, а количество свойств не увеличется и не уменьшится.
Я не про количество свойств, я про вес результата запроса.

-~{}~ 01.06.04 19:00:

2Falc

Я сделал 2 запроса, как ты и посоветовал. Используя массив.

Время работы скрипта увеличилось. ВРЕМЯ РАБОТЫ СКРИПТА, а не скорость запроса :)

Структуру я привел в посте чуть выше. Приблизительную, а большей и не требуется для того, чтобы понять то, что я хочу понять. Насколько я понимаю :(
 

Falc

Новичок
REMO
>>Я сделал 2 запроса, как ты и посоветовал. Используя массив.
Я кстати предупреждал что 2 запроса в большенстве случаев будет медленее одного.


>>Структуру я привел в посте чуть выше. Приблизительную, а большей и не требуется для того, чтобы понять то, что я хочу понять.

Ну тогда жди того кто ее поймет и даст тебе совет :)
 

REMO

Guest
Автор оригинала: Falc
REMO
>>Я сделал 2 запроса, как ты и посоветовал. Используя массив.
Я кстати предупреждал что 2 запроса в большенстве случаев будет медленее одного.


>>Структуру я привел в посте чуть выше. Приблизительную, а большей и не требуется для того, чтобы понять то, что я хочу понять.

Ну тогда жди того кто ее поймет и даст тебе совет :)
Я думаю, что тормоза связаны не со вторым запросом, а с тем что идет обработка массива. Это конечно ИМХО...

Что не понятного в структуре?

table1 id | name | description
table2 id | property

Таблица1: ай ди товара, название товара, описание товара...
Таблица2: ай ди товара, свойство товара...

Прошу обратить внимание. Мой вопрос в основном о том КАК ВЕС ЗАПРОСА БУДЕТ ВЛИЯТЬ НА СКОРОСТЬ ЗАПРОСА И ЗАГРУЗКУ БД.

Если как то можно поменять структуру данных, чтобы избежать прогрессивного увеличения ВЕСА запроса, 2Falc & Larson, скажите как...
 

Falc

Новичок
>>КАК ВЕС ЗАПРОСА БУДЕТ ВЛИЯТЬ НА СКОРОСТЬ ЗАПРОСА И ЗАГРУЗКУ БД

Вес результата запроса мало влияет на его скорость (конечно это не качается если ты гоняешь мегабайты информации).

>>Таблица1: ай ди товара, название товара, описание товара...
>>Таблица2: ай ди товара, свойство товара...

Теперь структура более понятна. Думаю что структуру менять не стоит.

>>чтобы избежать геометрического увеличения ВЕСА запроса
Нету там никакого геометрического увелечения веса.


Сделай выборку одним запросом и посмотри сколько он будет выполнятся, я думаю что гораздо меньше чем 0.5 сек.
 

REMO

Guest
Автор оригинала: Falc
>>КАК ВЕС ЗАПРОСА БУДЕТ ВЛИЯТЬ НА СКОРОСТЬ ЗАПРОСА И ЗАГРУЗКУ БД

Вес результата запроса мало влияет на его скорость (конечно это не качается если ты гоняешь мегабайты информации).

>>Таблица1: ай ди товара, название товара, описание товара...
>>Таблица2: ай ди товара, свойство товара...

Теперь структура более понятна. Думаю что структуру менять не стоит.

>>чтобы избежать геометрического увеличения ВЕСА запроса
Нету там никакого геометрического увелечения веса.


Сделай выборку одним запросом и посмотри сколько он будет выполнятся, я думаю что гораздо меньше чем 0.5 сек.
Скорость в среднем получается 0,45 сек...

Вот запрос, чтоб не быть голословным:
PHP:
SELECT * 
FROM products t1, place t2, prodacts_properties t3, properties t4
WHERE t2.place_id = t1.place_id AND t3.id = t1.id AND t4.id = t3.id AND print = 1 AND priznak = 1 
GROUP BY t1.id
ORDER BY RAND(".$number.")
Как только использую схему с 50 запросами все работает быстрее. Хотя я тестил на 15 тоарах. Возможно, что на 50 все булет наоборот?
 

Larson

Новичок
> Я не про количество свойств, я про вес результата запроса.
Да? А от чего зависит "вес результата запроса"? Не от количества ли возвращаемых данных.

Ты явно что-то бредишь про "вес". Сколько тебе нужно данных взять из базы- столько и бери. Хочешь сразу все возьми, хочешь по одной записи вытаскивай, но лишние там никак не могут появиться.

А куда ты собрался девать информацию о 50 товарах? На экран?

-~{}~ 01.06.04 19:57:

А теперь покажи свои 50 запросов.
 

REMO

Guest
Автор оригинала: Larson
> Я не про количество свойств, я про вес результата запроса.
Да? А от чего зависит "вес результата запроса"? Не от количества ли возвращаемых данных.

Ты явно что-то бредишь про "вес". Сколько тебе нужно данных взять из базы- столько и бери. Хочешь сразу все возьми, хочешь по одной записи вытаскивай, но лишние там никак не могут появиться.

А куда ты собрался девать информацию о 50 товарах? На экран?
Да на вывод...

Возможно и брежу :) Но я не раз встречал на форуме. Нагрузка на БД зависит не только от количества запросов, но и от того сколько инфы они выбирают. Т.е. веса.... Я не прав?
 
Сверху