@whats: мне очень интересно, как вы планируете в чистом mysql выбирать случайные записи.
Прочитал ваш ответ - ок, вы молодец, написали запрос который проставил всем row_number.
Дальше что с ним делать?
Качать все данные в php? Это жесть, там могут быть сотни тысяч значений.
Генерить id из php и писать запрос вида select * from (ваш запрос) where id in (1,2,3) - во первых вам придется делать отдельный запрос для нахождения максимального вашего id, а во вторых это будет нереально медленно в случае большого выбранного случайного id
@whats: не очень понимаю о чем вы - бизнес логика находится в php. Сложностей в настройке сфинкса на таких объемах нет.
Ну а заменить базу - это imho слишком суровое решение для одной мелкой задачи.
@whats: LIKE не будет работать быстрее чем предложенный мной вариант со сфинксом. Если вам кажется что он быстрее - отключите query cache в sql.
До кучи бесплатным бонусом сфинкс умеет делать морфологический поиск.
Вообще за реализацию поиска через LIKE надо убивать. Медленно и в муках.
Это настолько очевидно что я даже не хочу это аргументировать.
@worlxxaker а вы смешной :)
для опыта предлагаю вам купить 2 недорогих направленных антены и провесить в городе направленный канал хотя бы на пару километров.
В течении 3-4 дней к Вам придут :)
Проверялось многократно.
@tnorman я в свою очередь не приемлю постановку задачи в стиле "я хочу". К проблемам нужно подходить последовательно. Если у вас реально возникнет какая то не стандартная ситуация обосновано - тогда и надо придумывать хаки. Исходя из реальных бизнес-требований. Кстати зачастую в них и будет скрываться ответ.
Выдуманная из головы задача на основе вашей:
Нужно из мобильного приложения быстро грузить мелкий мелкий файлик с произвольным названием. Интернет медленный edge, процесс коннекта - дорогой.
Решение задачи из головы: пакуем файл и данные о названии в собственный контейнер, передаем одним запросом, на сервере расшифровываем.
Но это опять же решение вызванное какими то жесткими необходимостями и стеком технологий.
@MaM смотрите, все существующие решения - i2p, tor - работают поверх существующих протоколов и инфраструктуры.
Захотят это отрубить - отрубят физически.
У вас физически не будет возможности выйти соединением за пределы страны.
Какой то формат обмена информацией конечно останется. Вспомним FIDO.
Но будет это не в том виде что мы сейчас привыкли и на других скоростях.
1) основной массе людей - не нужен. мы к сожалению слишком привыкли к пиратству, но надо понимать что пиратство - это плохо. аналогично плохо торговать наркотиками, оружием, людьми итд.
3) мне кажется что все это работает пока людей в системе мало, ресурсы крошечные, нет требований к оборудованию и каналам. как только у вас возникнет ресурс с посещаемостью хотя бы 10 000 000 в сутки - тут же выяснится что в домашних условиях это все не захостишь.
известны персоналии = можно установить контроль.
@tnorman что значит хочу не хочу? Мы не в детском саду же. Я написал как делать ПРАВИЛЬНО. Если теоретизировать - можно например присваивать последнему загруженному файлу этого пользователя - можно много всяких хаков придумать - но это будет НЕ ПРАВИЛЬНО, не стабильно и тяжело в поддержке.
@Urukhayy
1) Вам объяснить как регистрируется домен? :) Идете на nic.ru, регистрируете, размещаете где нибудь dns ). Можно отдельный домен в принципе не регистрировать, слать из под основного, просто тогда придется и общую почту на яндексе размещать
5) swiftmailer.org/docs/introduction.html и далее по ссылочкам
@Skerrigan лучше это отдельными вопросами задавать.
Идея в том, что у Вас на сервере есть некий постоянно работающий демон к которому цепляются по сокетам клиенты и ждут обновлений.
Уведомить этот демон можно разными способами.
1) Можно открывать к нему сокет и писать туда (соответственно надо научить демон получать данные из сокета + подумать о защите что бы пользователи туда всякого лишнего не кидали)
2) Можно вместо этого использовать любое решение для очередей: rabbitmq, redis, итд
rabbitmq более мощная штука для очередей чем redis, там можно настраивать разделение одной очереди на несколько, дублирование и проч.
redis проще, его не нужно настраивать :)
Мы делали и так и так в зависимости от задачи:
В первом случае у нас так работал достаточно нагруженный чат.
Во втором случае демон на node.js while(true) получает данные из очереди.
php скрипты когда что то меняется кладут событие в очередь.
все :)
Сложно что то ответить если честно. Поищите еще исполнителей в других местах. Возможно Вам имеет смысл все таки найти технического человека и собрать команду фрилансеров под проект.
Без описания не очень понятно насколько адекватно соотношение стоимости и объема работ - но надо понимать, что любая студия в IT всегда имеет минимум 100% накрутки от себестоимости :)
@mistergalynsky Я искренне считаю что чем меньше логики находится в sql - тем оно лучше и проще в поддержке. Использование хранимых процедур со сложной логикой оправдано только в исключительных случаях исключительных проектов.
Тем более что как я написал выше - я не могу навскидку придумать безгеморойного способа для расчета первого и последнего дня недели из sql.
Прочитал ваш ответ - ок, вы молодец, написали запрос который проставил всем row_number.
Дальше что с ним делать?
Качать все данные в php? Это жесть, там могут быть сотни тысяч значений.
Генерить id из php и писать запрос вида
select * from (ваш запрос) where id in (1,2,3)- во первых вам придется делать отдельный запрос для нахождения максимального вашего id, а во вторых это будет нереально медленно в случае большого выбранного случайного id