Надо чтоб все users с уровнем 0 удалялись в определенное время, а те, кто заказал уровень 1 оставались не тронуты. Но удаляются все. Помогите понять что не так. Вот код:
Полная Версия: Проблемы с автоудалением из sql
| Цитата |
| <table> <tr> <? $c=array( "emlmp"=>"хххххххt@ххххххх.ru", "urlmp"=>"http://хххххххх.хх" );?> <? $sql777=mysql_query("select*from users where rang='0'"); while($row777=mysql_fetch_array($sql777)){ $refer=$row777['user'];?> <th><? $sql444=mysql_query("select*from orders"); $row444=mysql_fetch_array($sql444); $imranger=$row444['name']; if($imranger!=$refer): $kan=$refer; $sql555=mysql_query("select*from users where user='$kan'"); $row555=mysql_fetch_array($sql555); $dk=$row555['date']; $dmk=$row555['email']; $tem="Уважаемый, $kan! Мы вынуждены были удалить Ваш аккаунт из проекта $c[urlmp] , т. к. , Аккаунты 0 уровня удаляется автоматически и без предупреждения после 00:00 часов, кроме тех кто уже сделал заказ. Администрация проекта $c[urlmp] * Это сообщение сгенерировано и отправлено роботом. Отвечать на него не нужно."; if($dk!=date('Y-m-d')): mail("$dmk","$kan, Ваш Аккаунт Удален!","$tem","From: $c[emlmp]\n"."Content-type: text/plain; charset=windows-1251"); mysql_query("delete from users where user='$kan'"); mysql_query("OPTIMIZE TABLE `users`"); mysql_query("OPTIMIZE TABLE `rest`"); mysql_query("OPTIMIZE TABLE `parent`"); mysql_query("OPTIMIZE TABLE `users`"); mysql_query("OPTIMIZE TABLE `orders2`"); mysql_query("OPTIMIZE TABLE `orders`"); mysql_query("OPTIMIZE TABLE `mess`"); endif;endif; ?></th> <? }?> </tr> </table> |
Спустя 1 час, 20 минут, 55 секунд (9.02.2009 - 10:37) sergeiss написал(а):
Во-первых, надо бы комменты в тексте писать. Полезно и для себя, и для тех, кто код читает.
А во-вторых, вот смотри.
Сначала ты выбираешь тех, у кого уровень ноль. Тут непонятно, кстати, зачем ноль в кавычках? Он что, символьный?
Затем ты выбираешь ВСЕ заказы.
Следом за этим сравниваешь, есть ли в первой же строке заказов юзер из первой строки выборки юзеров. Если нет - то удаляешь юзера. Вопрос: а с какого перепуга они обязаны совпадать? Для данного юзера заказ может оказаться во второй или третьей строке.
Я бы предложил не мудрить, а сделать один запрос на выборку.
А во-вторых, вот смотри.
Сначала ты выбираешь тех, у кого уровень ноль. Тут непонятно, кстати, зачем ноль в кавычках? Он что, символьный?
Затем ты выбираешь ВСЕ заказы.
Следом за этим сравниваешь, есть ли в первой же строке заказов юзер из первой строки выборки юзеров. Если нет - то удаляешь юзера. Вопрос: а с какого перепуга они обязаны совпадать? Для данного юзера заказ может оказаться во второй или третьей строке.
Я бы предложил не мудрить, а сделать один запрос на выборку.
| SQL |
| SELECT * FROM users WHERE user NOT IN (SELECT user FROM orders where rang=0) |
Тут я предполагаю, что поле user есть в таблице orders. Это не указано явно у тебя в тексте, но подразумевается.
Далее ты берешь данные этой выборки, пробегаешь по ней, делаешь рассылку юзерам об удалении, и затем удаляешь. Можно по одному, можно сразу всех.
PS. Кстати (это не реклама
). Если бы ты использовал PostgreSQL, а не MySQL, то можно было бы сделать вообще всё очень "красиво", через один-единственный запрос. Там достаточно в конце запроса на удаление написать "RETURNING *", чтобы получить полный список обработанных строк. Которые можно (в твоем случае) использовать для рассылки почты. А данные уже удалены будут, не надо будет мучать сервак несколькими запросами .Та же фигня есть и для апдейта с инсертом. То есть, можно получить полный перечень новых (обновленных) данных.
Это просто ну очень удобно...
Спустя 1 час, 31 минута, 17 секунд (9.02.2009 - 12:08) Schut написал(а):
Спасибо!
Спустя 3 часа, 52 минуты, 20 секунд (9.02.2009 - 16:00) Alchemist написал(а):
небольшое дополнение и топикстартеру и sergeiss'у.
лучше переписать запрос так, чтобы не было подзапроса в IN (или NOT IN) условии. Причина - непонятно (мне) почему, но оптимизатор переписывает такой подзапрос как "связаный подзапрос", увеличивая таким образом время работы с O(M+N) до O(M*N), где М и N кол-во строк внешнего и внутреннего запроса соответственно.
http://dev.mysql.com/doc/refman/5.0/en/sub...strictions.html
ЗЫ: Из своего опыта могу сказать, что у меня был случай, когда использование подзапроса в IN конструкции замедляло работу скрипта в 500 раз. (больше 10 секунд, вместо 0,02 после изменения)
лучше переписать запрос так, чтобы не было подзапроса в IN (или NOT IN) условии. Причина - непонятно (мне) почему, но оптимизатор переписывает такой подзапрос как "связаный подзапрос", увеличивая таким образом время работы с O(M+N) до O(M*N), где М и N кол-во строк внешнего и внутреннего запроса соответственно.
http://dev.mysql.com/doc/refman/5.0/en/sub...strictions.html
ЗЫ: Из своего опыта могу сказать, что у меня был случай, когда использование подзапроса в IN конструкции замедляло работу скрипта в 500 раз. (больше 10 секунд, вместо 0,02 после изменения)
Здесь расположена полная версия этой страницы.