Макс

PDO?
Хотя какой-бы ни был инструмент - им надо уметь пользоваться. в принципе в sql-инъекциях нет ничего невероятного, и PDO дает все необходимые для защиты инструменты.

больше набор символов - менее реально забрутфорсить.

ставите плагин для вашего репозитария.
настраиваете job - добавляете проверку репозитария, как следующий шаг указываете Execute shell script - в нем пишите нужные команды.
пример
в общем никакой магии.

Сделайте временную таблицу с датами, далее LEFT JOIN с ней с условием, что day >=date_start и day =

не может соедениться. попробуйте попинговать, проверить, что сервис доступен. Посмотрите в логах ftp-сервера, есть ли попытки соединения.

счетчик итерации? через i++

поставьте просто радиатор на процессор. 12 на малинке Вы нигде не найдете - только 5 и 3.3

так а есть кому отвечать-то на 80ом порту?

качните sed - для txt/csv работает ОЧЕНЬ быстро. файлик в пару гигов парсит за несколько минут.

на роутере по URL?

группировка по городу/стране с сортировкой по рейтингу, не?

берем какой-либо срипт отсюда, и либо руками дописываем его имя перед "пастом" строки, либо как-то ассоциируем виндовую строку с этим скриптом.

если у Вас есть свой DBA (т.е. вы уже платите за сопровождение БД) или Вы сами DBА - можете выбрать п.2
в остальных случаях чаще всего выгоднее получается п.1.

демон ssh у Вас помер.
смотрите в логи, почему не стартует

Если Staging не влияет на Prod - то почему бы и нет? хотя это и не best practice.

у меня был подобный опыт - я тупо задерживался на работе на час-полтора. Пока мозги еще варят. Плюс в транспорте время можно тратить с пользой - как минимум подтягиват язык. Я так читал профильные статьи на английском - но для этого какой-то базис надо.

1. Count после, минус Count до - вот вам и сколько вставилось
2. не понял, а чем это отличается от вопроса 1?
3. нет. БД сама не запишет.