Владимир Коротенко, Вашим способом их нельзя обработать. Только с помощью создания условий для BETWEEN в случае если значение координаты x1 > x2, в таком случае нужно корректировать условие. В итоге моя задача будет решена вот так:
Создаем условие если широта левого верхнего угла прямоугольника больше чем широта правого нижнего угла прямоугольника (x1 > x2). Это будет означать, что выбранный прямоугольник пересекает координату Y (широту) там где склеивается координатная сетка.
Значит мое условие:
WHERE (`lat` BETWEEN '-7.987931' AND '6.775799') AND (`lng` BETWEEN '172.152671' AND '-168.106551')
Превратится в условие:
WHERE (`lat` > '-7.987931' AND `lat` < '6.775799') AND (`lng` > '172.152671' AND `lng` < '-168.106551')
Сергей, Не совсем, ведь перед отправкой задачи, мы обязательно должны указать очередь в которую отправляем задачу. А так же попытаться создать эту очередь, если она не создана, с помощью команды queue_declare
Спасибо за ваш ответ! Но ведь обмен по сути ничего не делает. Он никак не скрывает очереди. Клиенту все равно нужно знать в какую очередь он должен послать данные, чтобы они обработались правильно
Но получается, что при добавлении поста, я буду должен достать 100тыс записей из БД и сгенерировать из них 100 массивов отправив их в очередь.
По сути это довольно сложная операция, которая не должна выполняться во время создания поста.
Меня это натолкнуло на мысль, что можно ведь сделать так:
Отправляем задание в очередь {post_id: 123} - его берет консьюмер, получает 100к записей, создает 100 массивов с ID - отправляет в другую очередь, а там уже еще один консьюмер обрабатывает каждый массив и отправляет пуш.
Такое бывает?
edward_freedom, а если я задам вопрос "как авторизовать пользователя" это не будет подразумевать вопрос о том, что открывая любую страницу, этот пользователь не должен вводить пароль заново?
edward_freedom, правильно, а теперь предствиим, приложение получает список пользователей, ему так же нужно отобралить кто сейчас онлайн. Я вытаскиваю сначала юзеров из бд, потом беру id полученных юзеров и тащу их в редис, чтобы для каждого получить значение последнего визита. Затем мне нужно раскидать полученные данные в каждого юзера. Вот весь этот процесс и создаст постоянные переборы массивов с данными. С бд все было проще, я просто беру поле last_visit и отдаю его вместе со всеми остальными
DanKud, Сложность вытаскивания. Получается при любом запросе, мне по несколько раз придется перебирать полученные записи юзеров и добавлять к ним время из внешнего источника (Redis). Не знаю, возможно так и делают, поэтому и задаю этот вопрос. Мне просто этот вариант показался чересчур массивным
edward_freedom, это и есть мой первый вариант - я так и едлаю. Любое действие (открытие ленты, страницы, лайк или еще что-то. в общем любой запрос к серверу) - запрос в базу на обновление онлайн.
Спасибо за отклик!
Т.е. логика должна быть такая?:
Пользователь в ходит на сайт, определяем по IP города, берем данные о городе области и стране из GeoIP, сохраняем их таблицы countries, regions, cities в MySQL. У нас получится уникальный идентификатор каждой страны, региона и города. Привязываем их к пользователю и при необходимости вывода JOIN-им к основному запросу.
Но тут опять же - проблема. Если предложить пользователю выбрать город из списка самостоятельно, то придется использовать, какой-то другой сервис, т.к. GeoIP не отдает список городов определенной страны или области. Поэтому получив автоматически по IP город и сохранив его в базу, а потом позволив выбрать город из другой базы (сервиса) - мы сохраним второй такой же город в базе MySQL. А чтобы проверить его существование в моей БД MySQL - нужно его как-то унифицировать. Координаты? Может быть... Но ведь нет гарантии что координаты города в GeoIP точ в точ такие же как координаты этого же города, например в Goole Geocoding
xmoonlight, Мне кажется вы уже смешали фильтрацию и валидацию...
Я бы посоветовал создать создать класс синглтон RequestData в котором экранируются все магические кавычки, удаляются непечатаемые символы.
Во всем скрипте получать переменные через RequestData->get($param) зная что они уже экранированы, а валидацию оставить другим классам, чтобы было проще выводить ошибки или в зависимости от существующих/несуществующих данных выполнять разные классы и методы.
morricone85, А для чего вам вся иерархия? Я так понимаю для построения ЧПУ и Хлебных крошек?
Если так, что вам лучше отдельным запросом вытащить все категории и построить иерархию по полученному пути 1.7.3, который будет храниться в каком-то поле записи "статья".
Так у вас гораздо меньше ресурсов будет затрачено