FanatPHP

Для начала ответим на вопрос буквально:

конечно же, в настройках соединения прописано
PDO::ATTR_EMULATE_PREPARES => false

В этом случае - вообще незачем.
Если эмуляция отключена, то можно вообще никогда не указывать тип.

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

И вот если эмуляцию включить, то как раз и возникнет единственный случай, когда придется биндить с указанием типа: если у тебя в запросе передаются параметры в LIMIT. Если в запросе есть оператор LIMIT и в него передаются параметры, то их надо обязательно биндить через PDO::PARAM_INT - иначе запрос выдаст ошибку.
Мало того - передаваемые данные надо самостоятельно привести к типу int - PDO это за тебя делать не будет!

Теперь ответим в общем, объясняя твои многочисленные заблуждения:

1. Как тебе уже объяснили выше, инъекция - это не про сохранение в базе. Это именно про выполнение запроса. Так что тип поля в БД не имеет значения.
2. Инъекцию через PDO провести нельзя только если на 100% соблюдается условие "любые данные попадают в запрос только через плейсхолдеры" - просто самим фактом своего присутствия PDO ничего ни от кого не защищает. Кстати, соблюдение этого правила не так просто, как кажется. Решение для большинства нетривиальных случаев можно посмотреть здесь: phpfaq.ru/pdo
3. Самое важное: если мы используем плейсхолдеры, то все остальное уже неважно. Указывай какой хочешь тип, или не указывай вовсе - инъекции не будет. То есть, к безопасности твой вопрос про указание типа отношения не имеет.
4. Если ты не указал тип, то по умолчанию берется PDO::PARAM_STR. Это очень удобно, поскольку БД (по крайней мере - mysql) всегда корректно обработает любые данные, если они переданы, как строки

Так что, я думаю, что ты теперь и сам можешь ответить на вопрос, "зачем указывать тип".
И будешь писать просто

$sth = $dbh->prepare('SELECT * FROM fruit WHERE calories < ? AND colour = ?');
$sth->execute([$_POST['calories'],$_POST['colour']]);

Сначала надо подключить принтер...

https://www.google.ru/search?q=php+замена+подстроки

Поверь, это совсем несложно

• PDO -phpfaq.ru/pdo#in
• Mysqli - пол-экрана текста, так что без враппера совсем грустно.

Зато с враппером - всего дна строчка

$data = $db->getAll("SELECT * FROM news WHERE id IN (?a)", $json);

Изображения. В базу. Добавлять. Не нужно.

На самом деле тут всё сложно.
В идеале, все должно быть так:

В массиве объектов "таскать" за собой полное содержание статей

Потому что объект и должен, по идее, содержать все свойства сущности "Статья".

Но все эти прекрасные теории разбиваются о суровую действительность. Главных камня преткновения два:

1. Заведомая условность маппинга записи из таблицы БД на объект в программе.
2. Не бесконечная мощность компьютера, которая и заставляет нас не таскать текст статьи там, где нужно вывест только заголовок.

Поэтому мы идем на всяческие ухищрения. В частности, мы договариваемя сами с собой, что наш объект "статья" - это отображение записи из таблицы. То есть, он жёстко привязан к структуре таблицы в БД. И дальше мы делаем себе ещё одно послабление - при инициализации объекта мы сожем указать, что нам нужен только заголовок. И тогда код создаст объект, то у него будет заполнено только одно свойство.

Соответственно, ответ на первый вопрос - массив объектов, но урезанных, с одним заполненным свойством!

Ответ на второй вопрос кроется в том же маппинге: Описывая свой объект как отображение таблицы в БД, мы можем описать и связи этой таблицы! И тогда наш объект сможет автоматически "подтягивать" связанные данные, если мы к ним обратимся.

В момент записи.

База данных - не текстовый файл. И совсем не обязательно удалять объявление физически, чтобы оно больше не показывалась. В объявлении может быть такое поле как "последний день показа". И при выборке показывать только те объявления, у которых эта дата больше либо равна текущей.

Да, будет.
Нет, не критично.

Любой инстанс ПДО - это всегда отдельное новое подключение к БД, не важно, с к одной и той же, или к разным. В теории - это лишняя нагрузка на базу и желательно двух соединений избегать. Но если это не хайлоад, то большой проблемы не будет. Если хавйлоад, то надо осваивать современные технологии и не шарашить SQL прямо в коде, а использовать какую-нибудь интерллектуальную технологию, которая будет составлять запросы сама, и в том числе подставлять имя желаемой базы, беря его из настроек.

Несмотря на неграмотный заголовок (в момнт, когда пользователь закрывает браузер, никаких переменных уже нету, да и сам РНР скрипт давно умер), сама задача решается очень просто - стандартный механизм сессий идеально для неё подходит.

Но мне бы такое поведение показалось неудобным.
Было бы лучше, если бы введенные пользователем данные записывались в БД, и выводились при следующем заходе на сайт. А сборсить их всегда можно отдельной кнопкой

Неважно, одна это буква, или 10. Кодировка соединения с БД настроена неверно.
Нужно убедиться, что
- кодировка таблиц действительно utf8
- кодировка соединения(задается в mysql(i)_set_charset() или в DSN) - utf8
- кодировка страниц сайта - utf-8

Скорее всего, причина в повальной болезни современной школоты: фатальном неумении отслеживать причинно-следственные связи. Например, если при просмотре выводимых из БД данных, они отражаются неправильно, то делается вывод о том, что они записались неправильно. Или, как вариант - аффтар сам же совершает в коде какие-то глубокомысленные телодвижения, не понимая их смысла - просто потому что точно так же пацаны подсказали, а он тупо скопировал - и они-то как раз и портят данные.

Но в любом случае - проблема в неумении разделить процесс на этапы, и проконтролировать данные на каждом. Чтобы впоследстви хотя бы задать адекватный вопрос, типа "При передаче данных из браузера данные портятся". Или "при записи в БД данные портятся". Вместо этого мы получаем беспомощное "С данными что-то происходит, но что именно и в какой момент - ниняю".

Вам сюда.

Один из тех вопросов, от которых волосы встают дыбом. На всех частях тела.

Ну ладно - вопрос. От человека, который массив в первый раз в жизни увидел. Можно понять.

НО ОТВЕТЫ!!! "Тут какие-то заборы! Коровники! Мама, мы в аду! Мы в аду, мама!"

Возможно не пытаться украсть то что тебе не принадлежит, а заняться честным трудом.

При тех же трудозатратах можно получить большую, а - главное - честную прибыль.