egoss

Отчасти вы правы. >или вы PHP не используете в данном случае... Использую, движок пишу. В других движках я бы так и сделал. но в данном случае движок пишется (под заказ) с расчетом на большую нагруженность. Примерно 10 000 пользователей в сутки. по этому три запроса или один, существенная разница.

Задача, выдавать пользователю информацию о другом пользователе учитывая уровень доступа. Есть три таблицы 1. Таблица с пользователями `b_users` 2. Таблица уровней доступа к данным пользователя `b_uaccess` : 0 - доступен для всех; 1 - только для друзей; 2 - Только для автора +——————————+ | id | uid | email | icq | ...| +——————————+ | 1 | 1 | 1 | 0 | ...| +——————————+ В данном случае Пользователь номер 1 разрешил смотреть свой email только друзьям а ICQ могут видеть все. 3. Таблица "Друзей", в ней хранится информация о том кто с кем дружит `b_friends` +———————--+ | id | uid | fid | ...| +———————--+ | 1 | 1 | 2 | ...| +———————--+ В данном случае пользователь номер 1 дружит с пользователем номер 2. fid - Friend ID uid - User ID Сначала на автомате решил задачу выдачи данных пользователю о другом пользователе в три запроса, что не есть гуд. Вовремя опомнившись, начал искать решение получить данные одним запросом, учитывая права доступа для просматривающего. так как раньше имел дело только с простыми запросами типа SELECT * FROM `` WHERE ``='', пока удалось сделать только такой запрос. Вот его часть, получить емайл учитывая уровень доступа владельца к просматривающему. P.S. Запрос выполняется только в том случае если ID просматривающего не совпадает с ID просматриваемого. другими словами если я сам хочу посмотреть свои данные будет выполняться другой простейший запрос, где все данные будут доступны. /* E-mail */ SELECT IF( /* Если являются друзьями и доступ открыт для друзей*/ ( (SELECT `email` FROM `b_uaccess` WHERE `uid`=1)=1 AND ( SELECT `id` FROM `b_friends` WHERE `uid`=1 AND `fid`=2) IS NOT NULL ) /* Или если доступ открыт для всех */ OR ((SELECT `email` FROM `b_uaccess` WHERE `uid`=1)=0), /* Получить емайл пользователя */ (SELECT `email` FROM `b_users` WHERE `id`=1) /* В противном случае заменимить емайл на 'access denied' в выводе результата */ ,'access denied') AS `email` Но имхо ето не запрос, а безобразие. Почитал про запросы на mysql.ru, все теоретически понятно, а вот практики нахватает. Думаю, что можно составить более простой и компактный запрос. Интересует также как в таком запросе использовать алиасы, если возможно. Помогите, пожалуйста, упростить запрос. Заранее, всем спасибо.

Zend Studio

Функция substr

Необходимо авторизироваться на сайте под двумя учетными записями сразу по очереди. вроде ничего сложного. Инициализирую сеанс cURL в пхп, устанавливаю опции, отпрвавляю данные записываю куки в файл, прохожу location'ы, получаю содержимое. закрываю сеанс. все нормально. после ставлю таймаут sleep(30); к примеру и делаю тоже самое но отправляю другие данные для авторизации и она не прокатывает, в ответе получаю ошибку о неверном логине или пароле. Логин и пароль верные. Файлы для кукисов разные. записываются правильно. Авторизируется на сервере только первая отправленая учетная запись, вторая нет. пробовал менять порядок. user-agent разный для аккаунтов. Привязки к IP нету. Руками авторизиироваться на двух аккаунтах одновременно получается. Пример: <?php $ch1 = curl_init(); curl_setopt($ch1, CURLOPT_URL, $step1); curl_setopt($ch1, CURLOPT_HEADER, 0); curl_setopt($ch1, CURLOPT_COOKIEJAR, $cookie_file1); curl_setopt($ch1, CURLOPT_COOKIEFILE, $cookie_file1); curl_setopt($ch1, CURLOPT_USERAGENT, $user_agent1); curl_setopt($ch1, CURLOPT_POSTFIELDS, $auth_string1); curl_setopt($ch1, CURLOPT_POST, 1); curl_setopt($ch1, CURLOPT_FOLLOWLOCATION, 0); curl_setopt($ch1, CURLOPT_RETURNTRANSFER, 1); curl_exec($ch1); curl_close($ch1); sleep(30); // тоже самое для авторизации под другой учетной записью. $ch2 = curl_init(); ... ?> Если код разбить на два файла, то все работает правильно. т.е. первый авторизирует один аккаунт, второй соотвественно другой аккаунт. Всю ночь искал информацию. нашел пример использования недокументированных (на сколько мне известно) функций cURL для синхронного выполнения запросов. ссылка Сделал по аналогии, всеравно авторизацию успешно проходит только один аккаунт. Заметил, что при использовании последнего способа, cookie не записались в файл, и при етом один аккаунт, пройдя через два location'a, выдал мне страницу успешной авторизации. Предпологаю: Что cookie всетаки были отправлены. И еще предположение, что ошибка о неверноем логине или пароле, при попытке авторизироваться на втором по счету аккаунте, происходит опять же изза cookie, т.е. сервер получает cookie от одной учетной записи, а я посылаю реквизиты для другой. Предпологаю: Судя по информации с википедии Сокет и успешной работе скрипта, при условии 1 авторизация - 1 процесс Дело может быть в сокете который создает cURL, curl_close не решает ету проблему. есть другие способы не прерывая выполнение скрипта отчистить сокет? если ето так. Задача скрипта такая, нужно пройтись по некоторым страницам сайта под разными учетными записями, собрать нужную информацию и выйти. И два условия 1. прохожить по сайту нужно оченьл часто 2. необходим таймаут в районе 30 секунд Чтобы не запускать несколько процессов, хотелось бы реализовать все в одном, пока первая учетная запись на таймауте (таймаут высчитывается из количества аккаунтов и времени выполнения 1 прохода по сайту), выполняется проход с другой учетной записи, все в цикле. Етот вариант экономит ресурсы и время. Может быть есть более удобное решение для данной задачи? Кто что думает по етому поводу? Скажите пожалуйста, в чем может быть проблема. Спасибо. PS Авторизация на одном сервере в пределах одного домена. Код в самом верху без цикла, для наглядности, его тоже проверял. Думал о решении на сокетах, на практике получается очень не удобно, так что желательно всеже cURL. PSS Дайте пожалуйста хоть какойнибудь более менее полезный ответ. или может я задал настолько тупой вопрос, что он не заслуживает внимания? У меня начинает создаваться впечатление, что на других форумах меня просто игнорируют. надеюсь здесь такого не будет. Еще раз спасибо.