|
Задавайте вопросы, мы ответим
Вы не зашли.
Если тема поднималась и не нашел извиняюсь заранее, если так и будет прошу ссылку хотя бы дать на обсуждение.
Проблема:
В функции хранимой есть такая строчка:
DECLARE rCursor CURSOR FOR SELECT `title` FROM `books` WHERE `books`.`id` IN(1,2,3);
Так вот мне надо чтобы вместо IN(1,2,3) формироволось нужное мне условие в соответствие со входными параметрами.
Вообщем каким способом можно передать набор чисел в функцию и затем использовать их в этом условии?
Количество чисел впринципе неограничено и не известно заранее это может быть как одно число так и 50, больше врядли но думаю не стоит ставить жестко ограничения.
Через подготовленные выражения я так понимаю не получится? Не считая примеров с созданием временной таблицы, т.к. это делается для увеличении производительности и смысла тогда не будет в перенесении задач с пхп на мускуль.
Ну и попутно пара вопрос не по теме, но толковых замечаний не нашел(вохможно плохо искал):
1. Есть ли смысл переходить на хранимые функции даст ли это прирост?
При условиях:
а)запросы селект в цикле но мелкие(где-то по 2-5 запросов каждую терацию и примерно 10-20 итераций, запросы виды SELEC id, name FROM table WHERE id = $d)
б)один но тяжелый(9 join примерно и сортировка)
в)что-то среднее между ними(расплывчато конечно так что если что можно опустить этот пункт)
2.Впринципе как тут выполняются запросы что лучше много мелких один тяжелый, без разницы?
На этот сам мало представляю как отвечать поэтому если так ответить не получится, но есть ссылки на то как мускуль что выполняет в хранимках скиньте пожалуйста.
Но больше всего интересует основной вопрос конечно, остальное если что потестирую сам при разных условиях.
Заранее спасибо всем откликнувшимся.
---------
А ну и на будущее впринципе возможно формировать для курсора запрос динамически? То есть что-то типа DECLARE curs CURSOR FOR "SELECT sd FROM sd".
Скорее всего вопрос как-то легко решается но для мускуля почему-то не нашел решений, для некоторых БД условие WHERE можно просто строкой передавать, тут так можно?( DECLARE curs CURSOR FOR SELECT sd FROM sd WHRE "....")
----------
А ну еще забыл))) Как можно возвратить массив из функции? только строкой в xml или через разделители? Просто это тоже потом время на парсинг в пхп полученных данных, не съется ли все выигранное время парсингом?
Отредактированно deep (27.02.2010 11:30:12)
Неактивен
Динамически на сколько я знаю нельзя, но можно немного изменить условие, например так:
DECLARE rCursor CURSOR FOR SELECT `title` FROM `books` WHERE FIND_IN_SET(`books`.`id`, p1) <> 0;
Отредактированно byterus (27.02.2010 11:48:42)
Неактивен
Спасибо большое! действительно это помогло. пока впринципе только тут динамически нужно, так что теперь всего хватает покрайней мере на некоторое время))
Неактивен
Хотя нет(( Толи я что-то не понимаю толи phpMyAdmin неправильно показывает время....
Отображает строки 0 - 0 (1 всего, запрос занял 0.1693 сек.)
SELECT *
FROM `books`
WHERE FIND_IN_SET( `books`.`id` , "1" )
LIMIT 0 , 30
Отображает строки 0 - 0 (1 всего, запрос занял 0.0004 сек.)
SELECT *
FROM `books`
WHERE `books`.`id`
IN ( 1 )
LIMIT 0 , 30
Так не катит точно(( Смысла нету тогда в процедуре вообще, если она одну запись будет почти 200мс брать. Он индексы так чтоли не использует или что? Можно что-то сделать?
Неактивен
А чем Вам не нравится временная таблица и подготовленные выражения?
Неактивен
А чем Вам не нравится временная таблица и подготовленные выражения?
Подготовленные выражения - медленно (оно делается больше 0.01 с, если мне не изменяет память).
Временная таблица тоже не очень, но если делать в MEMORY - нормально, где-то 0.0001 (именно на само создание таблицы).
Неактивен
Временные таблицы из-за скорости, ну и честно говоря потому что точно не знаю механизмов и не представляю какие могут быть последствия... Ну еще одна косвенная причина что нельзя в функциях использовать только в процедурах, ну если окажется что это лучшее решение, то возможно так и сделаю.
Ладно тогда сначала, если не сложно будет посоветуйте:
Допустим есть скрипт на пхп что-то вроде 1 вариант:
$res1 = $db->query("SELECT * FROM table1 WHERE id IN(1,2,3,4,5));
$res2 = $db->query("SELECT * FROM table2 WHERE id IN(1,2,3,4,5));
$res3 = $db->query("SELECT * FROM table3 WHERE id IN(1,2,3,4,5));
Далеее их перебор через fetch_assoc и получение результирующего массива на основание этих запросов
2 вариант:
Все это сделать JOIN за одну выборку
3 вариант:
в цикле для $res1 делать две другие выборки с условием id IN($i)
Я так понимаю быстрее и менее всего грузит 1 вариант?
Правда id не всегда так хорошо доступны, возможно надо сначала пройтись по первому запросу, а далее на основание результата делать уже 2 и 3, но тут без разницы все равно вроде линейно получается.
И вопрос по хранимкам: Какаой из этих вариантов есть смысл перекладывать на хранимки впринципе или ни какой? Я предполагал именно переложить то есть впринципе оставить примерно тот же код, но в хранимке. Или есть смысл перекладывать но с изменениями? Или лучше вообще 4 вариант?
Спасибо за ответы заранее. Кстати единственный форум где так быстро отвечают по программированию пока)) В выходные извиняюсь сам не мог ответить, не заходил.
Неактивен
Я бы сказал, что в 99.9% случаев Вы не заметите разницы в производительности
между этими тремя вариантами, а в том 0.1% случаев, где заметите, я Вам поре-
комендую избавиться от PHP — выиграете куда больше в производительности 
Неактивен
