Сергей Семенко: ну при росте проекта становится недостаточным. А по сути если проект небольшой - маленькое веб-приложение или просто сайт - то такой смех это наверное просто снобизм, мол, реальные парни деплоят через docker, git прошлый век. А по факту git pull отлично выполняет свои задачи при проектах соответствующего размера и сложности. Как только деплой начинает заключаться не только в обновлении backend кода, а в применении кучи миграций, обновлении конфигов, прогреве кэша, и все это на нескольких серверах - разумеется гита уже не будет хватать. Но когда проект становится таким - вопрос уже звучит не как "ftp или git pull", и проблемы появляются другого уровня ;)
Оптимус Пьян: да, на боевом сервере тоже git. собственно даже на недорогих виртуалках с доступом по ssh гит есть почти всегда.
Миграции - это описание манипуляций с базой данных в php коде. Во всех популярных фреймворках они есть из коробки, если не повезло и проект legasy - то можно поставить например phinx через composer.
Как работают миграции: если надо добавить новую таблицу в базу / новую колонку - то ты не просто тупо заходишь в phpmyadmin и выполняешь там что хотел - если в команде больше одного разработчика и у каждого по локальной базе, + на девелопе/проде еще по одной - поди зайди в каждом и напрямую создай. У кого-то забудешь, опечатаешься - и сломается что-то, а что - придется вручную искать.
Обычно пишут миграции - классы, имеющие метод up и down , условно. Допустим up создает таблицу и новую колонку, down удаляет их, т.е откатывает базу к предыдущему состоянию. Т.е есть метод применения изменений, и их отката. Миграции выполняются последовательно, т.е можно их десяток написать при работе над задачей, не держа в голове, что ты там локально наменял, а потом разом применить на проде.
Прелесть этого подхода в том, что один раз описал - потом применяешь на любом количестве серверов одной простой командой с возможностью отката. Плюс изменения структуры базы логируются в коде, и всегда можно найти, что где сломалось и пошло не так
Stasgar: Совершенно неперсистентная работа с данными. Нельзя откатиться к какому-то состоянию, файлы меняются не одновременно, может произойти сбой в момент заливки и замены файлов (например место кончилось на сервере), и зальется не целиком проект, невозможность применять миграции. Да причин действительно слишком много. Как минимум после перехода на более совершенные способы деплоя ftp становится уже субъективно дико неудобным)
Александр: А выдержка из официальной документации по ссылке, очевидно, лжет : Параметры подготовленного запроса не требуется экранировать кавычками; драйвер это делает автоматически. Если в приложении используются исключительно подготовленные запросы, разработчик может быть уверен, что никаких SQL инъекций случиться не может (однако, если другие части текста запроса записаны с неэкранированными символами, SQL инъекции все же возможны; здесь речь идет именно о параметрах).
Prepared statements не спасут на 100%, но этого я и не писал. Все что я написал - это то, что биндинг параметров как в вопросе легко может привести к sql injection
AndreyBerezov: фраза была "для начала даже git-a по ssh хватит" , т.е когда весь процесс деплоя сводится к коммиту и пушу на удаленный сервер с локальной машины в мастер ветку, и последующему pull-у на рабочем сервере из нее же. Для многих проектов этого достаточно.
Потом, когда появятся запускаемые миграции, тесты, компрессии файлов, разогрев кэша, прекоммит-хуки, полноценный процесс разработки, например по GitHub Flow, и прочие прелести все усложняемых проектов - придется многое или после пулла вручную делать, или, что правильнее, автоматизировать.