Ограничение на размер SQL запроса

[Shasoft]

Есть массив идентификаторов $IDS в количестве N
Нужно выполнить

UPDATE mytable SET a=1 WHERE ID in (все значения из массвива IDS)

Я рассматривал 3 основных варианта:
1. Вариант, по которому задавался вопрос. Т.е. преобразовать массив implode(",",$IDS) и вставить это в запрос
2. В цикле пройти по массиву и выполнить N запросов для каждого идентификатора
3. Если есть ограничение на размер запроса, то выполнять запросы не по каждому идентификатору, а к примеру порциями по 100-1000 шт

Вариант 2 я отбросил, так как, на мой взгляд выполнять так много запросов - это "не есть хорошо".
Для выбора из варианта 1 и 3 я и задавал вопрос. Теперь выбор очевиден - вариант 3.

"Возможных вариантов решения много" - это уже больше относится к практическому решению, так как в теории - массив $IDS у меня есть, но на практике я его тоже собираю из дерева и надо будет ещё подумать, в каком месте вставить "порционное" обновление.

 

[Фанат]

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

 

[Shasoft]

И при чем тут человеческая работа с деревьями?
Я про это не спрашивал и не писал, как я это делаю. Или это это такой ценный совет "по-человечески работай с деревьями"?

 

[zerkms]

Shasoft
да. если бы деревья хранились удобно - то у тебя не было бы проблемы с IN(...)

 

[x-yuri]

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

Shasoft так ты может подробнее задачу опиши ;-)

 

[Shasoft]

Тогда сорри. Вы наверное не совсем поняли. Идентификаторы я собираю с дерева, но обновления провожу НЕ по таблицы дерева.
Т.е. указанная таблица mytable содержит не дерево.
Правильное хранение дерева может повлиять только на скорость собирания идентификаторов с дерева, но к IN(...) это отношение не имеет.

 

[Сергей Тарасов]

Мда... Рома вообще был прав.
Зачем делать через задницу???

Ну хоть так как-то:

SELECT * FROM xxx WHERE y IN (SELECT y from xxx WHERE z)

 

[Shasoft]

В таблице z хранится дерево в виде
ID, IDPARENT
и нужно вытащить раздел, все дочерние подразделы, дочерние дочерних т.д.
Таким простым SELECT нужные идентификаторы не вытащишь.

 

[Сергей Тарасов]

Shasoft

Ты спросил про IN, тебе ответили.

 

[Shasoft]

Я спросил про ограничение на размер SQL запроса, а не про IN.

Но мне всё-равно ответили.

 

[Сергей Тарасов]

Shasoft

Ну видишь ли, дело в первую очередь то не в размере пакета, а в том, что это строка и на той стороне ее нужно разобрать, чтобы построить запрос и поэтому SQL-запрос в 10 тыс. элементов в IN - не лучше решение))

 

[Shasoft]

Сергей Тарасов
В данном случае скорость не так важна. Главное сможет ли такой запрос вообще выполнится. Я думаю, что уж секунд за 15-20 такой запрос сможет по-любому распарситься.

 

[DiMA]

Shasoft
ты уймешься когда-нибудь? Любой пободный (крайне простой) запрос, не длиннее max_allowed_packet, будет выполнен. Никаких ограничений и проблем нет. На парсинг строки запроса уйдет много меньше секунды. На тупой поиск по примари кей - тоже копейки. Апдейт - немного задумается.

 

[Shasoft]

DiMA
Я то уже давно получил ответ и вроде уже неоднократно об этом писал. То, что вы написали, я понял после вашего ответа.
Про 15-20 секунда я написал, чтобы люди поняли, что даже ТАКОЕ время запроса меня вполне устроит. А уж насколько оно будет меньше, это уже практика покажет.