DevMan, это актуально для unix timestamp используемого в операционной системе, в СУБД кол-во байт для хранения unix timestamp жестко фиксировано и не зависит от разрядности ОС. В любом случае, в документации указано ограничение 2038 годом, да и на практике также.
Ускорение в 100-1000 раз? Позвольте не поверить.
Да, в некоторых ситуациях асинхронность и постоянность ws будет отличным решением (те же spa с постоянным подключением), но в других многопоточность выиграет (к примеру, нужно дать не быстрый ответ, или непостоянные подключения, ведь подключение к ws не быстрое). Имхо, для разных ситуаций, разные инструменты.
Konstantin Vasin, да, тут нужно понимать принцип работы запроса, сперва он проходит и выбирает пары с заданными ключ-значение, затем проверяет группировкой что было выбрано 2 пары, при описанных условиях будет работать.
Это не очень очевидно, но с SQL часто так.
ThunderCat, говорю ж тупанул, как-то не подумал о том, что вопрос о динамическом SQL и имена полей можно забирать прямо из запроса и фигачить в запрос.
Тогда это не код-ревью, к сожалению. Действительно, для разных ситуаций будут предпочтительнее разные запросы, join для 2 больших таблиц, in если вторая маленькая, в общем случае. Хотя здесь скорее всего виноват like, как самый прожорливый, и индекс по полю не поможет, т.к. вы ищите не начало строки, а вхождение.
Добавлю, что, "Во всех руководствах по настройке FTP-сервера «vsFTPd» рекомендуют настраивать так называемые TLS/SSL" это называется FTPS, но проще использовать SFTP - это ftp через ssh-туннель.
jazzus, логический оператор ИЛИ, это четкое математическое выражение, какие "бесчисленные варианты"? Cron выполнит команду при истинности первого или второго условия, т.е. в этом варианте, во все дни 1-7,15-21, а в остальные дни по понедельникам.
DevMan, в любом случае файл перезаписывается целиком, как иначе? Так ведь проще. Антон Р., мне кажется, что пользовательские данные должны лежать в БД, зачем нам она, если храним файликах? Нужно будет поставить несколько бекендов - не возникнет проблем, при их замене также нет проблем, при деплое не нужно будет генерировать новый такой файл конфига и игнорировать его при обновлении. Если, конечно, все это не планируется использовать, то и так сойдёт.
RaDir, какая разница где реп, в любом случае придется делать composer update? Можно делать жёстко, менять composer.lock, тогда достаточно composer install. Либо как уже советовали держите в ветке разработки в одном виде, в ветке релиза меняйте на стандартную, но если не автоматизировать, то можно забыть.
bozuriciyu, технически, вы можете использовать любой метод как вздумается, слать GET с параметрами в body, или POST с параметрами в path, что там логически вообще не важно. А вот что вопрос поддержки не беспокоит - это печально, даже если сейчас кажется что это и не нужно вовсе.
Антон Р., ужас страшный. Как движок реализует - это странный вопрос, открывает файл и пишет в него, нет ничего проще. Но стоит ли так делать? Есть БД и изменяемые данные хранят там. Можно, конечно, и так. Если приложение не будет масштабироваться, то и так сойдёт.
