FanatPHP

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

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

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

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

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

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

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

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

Процедурный однозначно.
Если такой вопрос в принципе возникает - это значит, что ООП автор не понимает от слова "совсем". И в итоге, при попытке написать собственные классы, получит адский треш. Поэтому только процедурный. Там тоже будет треш, но не адовый.

Более сложный вариант - посмотреть на календарь, узнать, что сейчас уже вторая декада XXI века, и перестать уже наконец использовать РНР так, как его использовали в прошлом тысячелетии, ковыряя каждую мелкую задачу самостоятельно на чистом РНР. После этого взять учебник по современному фреймворку, такому как Ларавель или Йии, прочитать его, и начать делать сайт с помощью готовых классов, которые уже написали для тебя, и которые берут на себя 80% черновой работы, и при этом делают её на 100500% лучше, чем твой собственный самопальный код (потому что учитывает миллион нюансов и правил, о которых ты вообще даже не подозреваешь). В итоге, по факту, сайт получится с использованием ООП, но не в том смысле, который имел в виду автор (писать все самому с нуля).

Суть, на самом деле, в том, что

Первое: портируя свой код с "процедурной модели" на "объектно-ориентированную" аффтар умудрился не заметить цикл, который был в первой, но испарился во второй. Но виновата оказалась модель ООП РНР.

Второе и самое главное: портируя свой старый говнокод с mysql_* аффтар осилил только добавление буковки i и стрелочек, всё остальное оставив как есть. Получив в итоге ровно тот же самый говнокод, что и раньше.

Для справки:
Смысл перехода с mysql на mysqli не в том, чтобы добавить палочку с точечкой. А в том, чтобы использовать подготовленные выражения.
Смысл ООП не в том, чтобы писать палочки с угловой скобочкой. А в том, чтобы объект инкапуслировал внутри себя всю работу по обработке данных, возвращая сразу желаемый результат. В итоге код, реально использующий ООП, должен выглядеть как-то так:

$sql = "SELECT `service` FROM `service_synonyms` WHERE `synonym` LIKE ?";
$result = $this->_dbconn->getAll($sql, "%$query%");