Larson
Новичок
>Я не прав?
Прав. Только смотрю в книгу- вижу фигу.
Не в твоем случае.
У тебя суммарный объем возвращаемых данных в обоих случаях должен быть одинаковый, а следовательно его "вес", т.е. объем данных постоянный.
-~{}~ 01.06.04 20:24:
Обычно на один экран выводят фиксированное число элементов (даже если их и 50). Так что ни о каком "прогрессивном" гипотетическом росте возвращаемого объема данных не должен стоять вопрос. Величина постоянная. Скорость в данном случае будет зависеть от объема данных, хранимых на сервере БД (скоростью выполнения скрипта пренебрегаем, т.к. тоже велечина постоянная).
Прав. Только смотрю в книгу- вижу фигу.
Не в твоем случае.
У тебя суммарный объем возвращаемых данных в обоих случаях должен быть одинаковый, а следовательно его "вес", т.е. объем данных постоянный.
-~{}~ 01.06.04 20:24:
Обычно на один экран выводят фиксированное число элементов (даже если их и 50). Так что ни о каком "прогрессивном" гипотетическом росте возвращаемого объема данных не должен стоять вопрос. Величина постоянная. Скорость в данном случае будет зависеть от объема данных, хранимых на сервере БД (скоростью выполнения скрипта пренебрегаем, т.к. тоже велечина постоянная).
REMO
Guest
PHP:
+-------+--------+-----------------------+---------+---------+----------+------+---------------------------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+-------+--------+-----------------------+---------+---------+----------+------+---------------------------------+
| t4 | ALL | NULL | NULL | NULL | NULL | 20 | Using temporary; Using filesort |
| t3 | ref | id, id | id | 1 | t4.id | 47 | |
| t2 | ALL | NULL | NULL | NULL | NULL | 152 | |
| t1 | eq_ref | PRIMARY,priznak,print | PRIMARY | 2 | t3.id | 1 | Using where |
+-------+--------+-----------------------+---------+---------+----------+------+---------------------------------+
4 rows in set (0.01 sec)Это у хостера, не понятно правда почему выборка всего 4 строки (видимо, что то я напутал в запросе). И скорость я так понимаю 0,01 сек.
На локалке я мерил скорость микровремя перед запросом, микровремя после запроса... И было 0,5 сек...
2Larson
Первый запрос:
PHP:
SELECT *
FROM products
WHERE print = 1 AND priznak = 1
ORDER BY RAND(number)Второй в цикле для каждого товара:
PHP:
SELECT *
FROM place t1, products_properties t2, properties t3
WHERE t1.place_id = $row[place_id] AND t2.id = $row[id] AND t3.uslid = t2.uslid
Falc
Новичок
REMO
И что ты хочешь с таким explain'ом получить?
Где твои индексы? потерялись?
У тебя проблема не с количеством данных с незнанием того что такое оптимизация запросов.
Почитай ман, и поищи мою статейку на деталях может поможет.
Кстати ты расказывал что у тебя 2 таблицы, а в запросе целых четыре откуда еще 2 нарисовались из подземли выросли?
И что ты хочешь с таким explain'ом получить?
Где твои индексы? потерялись?
У тебя проблема не с количеством данных с незнанием того что такое оптимизация запросов.
Почитай ман, и поищи мою статейку на деталях может поможет.
Кстати ты расказывал что у тебя 2 таблицы, а в запросе целых четыре откуда еще 2 нарисовались из подземли выросли?
Larson
Новичок
Я же сказал 50 
Ну и что мы тут видим?
На счет скорости спорить не буду. Это разговор отдельный.
Я все про твой "вес". Твой запрос, который в цикле, это выборка данных из первого запроса. А т.к. ты рассматриваешь весь набор идентификаторов, то соответсвенно ты выбираешь все записи из первого, но по чуть-чуть.
Другими словами, ты в обоих случаях выбираешь все записи из одной таблицы, с одинаковыми условиями в том и другом варианте.
-~{}~ 01.06.04 20:53:
Да, и еще на счет "ненужных данных", о которых ты говорил в самом перво посте - нахрена ты во всех запросах поставил *? Брать нужно только то, что нужно.
Ну и что мы тут видим?
На счет скорости спорить не буду. Это разговор отдельный.
Я все про твой "вес". Твой запрос, который в цикле, это выборка данных из первого запроса. А т.к. ты рассматриваешь весь набор идентификаторов, то соответсвенно ты выбираешь все записи из первого, но по чуть-чуть.
Другими словами, ты в обоих случаях выбираешь все записи из одной таблицы, с одинаковыми условиями в том и другом варианте.
-~{}~ 01.06.04 20:53:
Да, и еще на счет "ненужных данных", о которых ты говорил в самом перво посте - нахрена ты во всех запросах поставил *? Брать нужно только то, что нужно.
REMO
Guest
Что то я не понял?Автор оригинала: Larson
Я же сказал 50
Ну и что мы тут видим?
На счет скорости спорить не буду. Это разговор отдельный.
Я все про твой "вес". Твой запрос, который в цикле, это выборка данных из первого запроса. А т.к. ты рассматриваешь весь набор идентификаторов, то соответсвенно ты выбираешь все записи из первого, но по чуть-чуть.
Другими словами, ты в обоих случаях выбираешь все записи из одной таблицы, с одинаковыми условиями в том и другом варианте.
За умными словами и словосочетаниями, я потерял суть...Ты хочешь сказать, что делать это одним запросом и 50 запросами это одно и то же?
Но ведь у нас в каждой строке (если мы будем один запрос делать) висеть текст из 300 символов. А строк будет столько сколько свойств у товара и умножить на количество товаров.
А если 50 запросов, то текст в 300 символов будет всего лишь в 50 строках, по количеству товара.
2Falc
Хочу всего лишь понять
С индексами разберусь, прежде еще раз статью почитаю. Читать ман не зная что там ищешь какой смысл? Что в мане читать?
Ну 2 таблицы это я упрощенно привел, чтобы о сути вопроса спросить
Кстати я так понимаю скорость все таки 0,01 сек, я правильно понимаю?
Larson
Новичок
В результате у тебя должен получиться один итот же набор данных, что при одном запросе, что при 50. Если конечный результат расходится значит ты решаешь разные задачи. В твоем случае множество получаемых значений в первом случае, принадлежит множеству значений второго варианта и поэтому тебе кажется, что они одинаковые, т.к. ты не мотришь дальше первого множества. А они должны быть равны, т.к. у тебя стоит задача, получить какой-то КОНКРТНЫЙ набор значений.
Пример.
Тебе нужно накопать небольшой мешок земли, чтобы посадить дома цветы. Неважно чем ты будешь копать землю - лопатой, совком детским, руками и т.п. в результате тебе больше мешка все-равно не надо (да и не унести). Ты же для этой цели пригоняешь экскаватор. В результате у тебя мешок все-равно будет набран, но экскаватором решают другие задачи и оглянись, какую яму ты там вырал.
Пример.
Тебе нужно накопать небольшой мешок земли, чтобы посадить дома цветы. Неважно чем ты будешь копать землю - лопатой, совком детским, руками и т.п. в результате тебе больше мешка все-равно не надо (да и не унести). Ты же для этой цели пригоняешь экскаватор. В результате у тебя мешок все-равно будет набран, но экскаватором решают другие задачи и оглянись, какую яму ты там вырал.
REMO
Guest
Млин, тебе в философы надо. Сколько не накопай, все равно больше мешка не унесешь
>"Должен получится один и тот же набор данных"
Именно, но в первом случае (один запрос), мы потащим еще мешков 5 с собой. Данных, повторных.
Мне кажется мы друг друга не дгоняем. Я не догоняю, зачем ты мне про то рассказываешь, что я больше того, что мне нужно не собираюсь уносить и поэтому мне надо рыть лопатой, а никак не эскалатором
Я не вижу в этом аналогии с тем, что в превом случае (когда все одним запросом). Этот запрос будет весить 500Кб (к примеру), а во втором эти 50 запросов будут весить 100Кб (к примеру).
Все что я хочу понять, это МЕЖДУ ЧЕМ ВЫБИРАТЬ?
Один но 500Кб. Или 50 , но по 100Кб.
Видимо я опять не догнал, того что ты мне хотел сказть. Ну вечером не так мозги уже работают, не так
Larson
Новичок
Ах вот про какие ты лишние данные.
Ну если тебя беспокоят эти 300 символов, то это тоже самое, что 300 коп. vs 300$.
Выбирай все одним селектом, но без этих 300 символов, а эти 300 симлов выберешь отдельно одним запросом для всех товаров сразу.
-~{}~ 01.06.04 21:37:
>Один но 500Кб. Или 50 , но по 100Кб.
Ну а самому посчитать?
Ты еще забыл свои 50 запросов умножить на количество пользователей, которые будут пользоваться данной приблудой.
REMO
Guest
Ну наконец то поняли друг друга
Т.е. не стоит по ним (линим данным в каждой стоке) заморачиваться и делать все одним запросом.
А если товаров будет 150, на 20 свойств, 3000 строк и в каждой по 300 символов текста...
Двумя запросами это значит через массив, а это ситуацию ИМХО не меняет, только все медленне работает
REMO
Guest
300 символов это у каждого товара... Придется делать запрос на все 50 товаров, затем засовывать эти описания в ассоциативный массив. Как Falc предложил
Larson
Новичок
Да при чем здесь эти 300 символов.
Зачем их все сразу запихивать в массив?
Есть два результата, полученных из БД. В одном содержаться описания товаров (или что-там эти 300 символов) в другом все свойства товаров. Спокойненько, не спеша идем по свойствам, просматриваем каждое, а как только перешли на следующий товар - из первого достали следующее описание.
Зачем их все сразу запихивать в массив?
Есть два результата, полученных из БД. В одном содержаться описания товаров (или что-там эти 300 символов) в другом все свойства товаров. Спокойненько, не спеша идем по свойствам, просматриваем каждое, а как только перешли на следующий товар - из первого достали следующее описание.
REMO
Guest
Я тоже так думал
Но тогда скажи мне как синхронизировать запросы, т.е. сделать так чтобы ID товара шли синхронно в запросах.
В свойствах скажем 101, ..., 101, 102, ..., 102, ....
В описниаях 101, 102, ....
Если в первом, где я выбираю, используя ORDER BY RAND(число) или другую сортировку... (ORDER BY что то еще), второй как отсортировать так же по ранду.
ORDER BY t1.id RAND (число) не работает, да как я понимаю и не должен...
Falc
Новичок
REMO
Ты занимаешься полной ерундой.
У тебя пролема в одном, а ты пытаешься найти ее в другом (как в анекдоте я ищу тут потому что тут светлее).
Твоих знаний не хватает чтобы найти истиную проблему и ты пытаешься искать ее там где хватает твоих знаний, но это не верно.
>>Читать ман не зная что там ищешь какой смысл? Что в мане читать?
Оптимизации запросов там посвещена специальная глава.
ПОВТОРЮ ЕЩЕ РАЗ, ТВОЙ ЗАПРОС ТОРМОЗИТ СОВСЕМ НЕ ИЗ-ЗА КОЛ-ВА ВЫВОДИМЫХ ДАННЫХ, ПРИ ТВОЕМ КОЛ-ВЕ ДАННЫХ ( 300 БАЙТ) ЭТО ВООБЩЕ НА СКОРОСТЬ НЕ ВЛИЯЕТ.
Ты занимаешься полной ерундой.
У тебя пролема в одном, а ты пытаешься найти ее в другом (как в анекдоте я ищу тут потому что тут светлее).
Твоих знаний не хватает чтобы найти истиную проблему и ты пытаешься искать ее там где хватает твоих знаний, но это не верно.
>>Читать ман не зная что там ищешь какой смысл? Что в мане читать?
Оптимизации запросов там посвещена специальная глава.
ПОВТОРЮ ЕЩЕ РАЗ, ТВОЙ ЗАПРОС ТОРМОЗИТ СОВСЕМ НЕ ИЗ-ЗА КОЛ-ВА ВЫВОДИМЫХ ДАННЫХ, ПРИ ТВОЕМ КОЛ-ВЕ ДАННЫХ ( 300 БАЙТ) ЭТО ВООБЩЕ НА СКОРОСТЬ НЕ ВЛИЯЕТ.
Larson
Новичок
Короче, РЕМО. Специально для тебя. Если тебя так уж сильно беспокоит перегонка твойх 300 байт на каждый товар, делай один запрос с ORDER BY RAND и помещай его результат во временную таблицу. А оттуда уже бери по отдельности.
-~{}~ 02.06.04 12:08:
Только памяти это будет занимать еще больше.
-~{}~ 02.06.04 12:08:
Только памяти это будет занимать еще больше.
REMO
Guest
Я правильно понимаю ваш месседж мне.
Сделать все одним запросом и оптимизировать его?
Сделать все одним запросом и оптимизировать его?
REMO
Guest
Столбцов в результате запроса около 20. Не уникальные данные (повторяющиеся) идут в строках.