FernandoErrNando

Когда в руках молоток, все вокруг становится похожим на гвоздь... Если вы хорошо разбираетесь в языках запросов, это не говорит о том что это распространенный навык.
Самый простой аргумент - посмотрите на рынок, много ли движков, построенных на бд/sql?
Много ли специалистов по бд вообще на рынке труда?
Кто из них разрабатывал логику на стороне бд?
Кроме того, слои яп-бд можно разнести на разные инстансы, что сильно распределит нагрузку, а бд сама по себе умеет в пожрать ресурсы...

Можно долго перечислять плюсы и минусы. Смысл в том что если вы будете разрабатывать это сами или для себя и вы уверены в собственной способности построить всю логику на одной технологии- флаг в руки, это будет оригинальным решением, вполне возможно даже что найдутся ценители.
Если же проект для заказчика, и в разработке будут участвовать 2+ людей, то тут то вы хапнете проблем большой ложкой. Найти спецов которые прям пишут логику на скуеле, чтобы они стоили приемлемых денег, завтра не ушли в другой проект так как тут надо делать кучу непрофильных дел: как-то делить задачи, вести версионирование, не пересекаться с другими задачами функционалом... проще пойти в нормальную контору, где от дбшника требуют только структуру, пару триггеров и он там один отвечает за бд, так как больше не нужно и ни с кем из коллег не надо 10 раз утверждать изменения в структуре/процедурах/етц. Короче это не специфично и мало кто захочет все это изучать с новой стороны. Про поддержку такого чуда я вообще молчу.

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

У каждого из подходов есть свои преимущества и недостатки.
К недостаткам можно отнести:

• Сложность отладки и тестирования
  
• Затрудненная версионность
  
• Зависимость от конкретной СУБД
  
• Ограниченные возможности языка
  
• Сложности с масштабированием
  
• Возможные side-эффекты
  

К преимуществам:

• Уменьшение трафика
  
• Цетрализованная логика
  
• Безопасность данных
  

Самое главное - ничего не писать на Yii 1.1

Если хотите изучить какой-то фреймворк, то учите ларавель

Если для сайта пишется своя собственная система управления контентом, то обычно она называется админкой, а не CMS

GROUP BY, MAX(), HAVING

Как правильнее было бы реализовать это?

Не изобретать велосипед, а погуглить готовые решения для очередей.
Беглый поиск:
https://www.npmjs.com/package/queue
https://github.com/bee-queue/bee-queue
https://levelup.gitconnected.com/how-to-implement-...
Ну и всякие там rabbitmq и т.п.

Создайте пустую базу на своем сервере.
Поменяйте настройки подключения в .env файле на свои.
Выполните миграции.
Если это локальный сервер разработки, возможно в проекте есть сиды для тестового наполнения данными. Тогда после миграций запустите сидирование.

$query = Content::find();

if ($where){
  $query->where($where);
}

$items = $query->all();

Модель следует назвать Setting
Таблицу settings
Сделать вторую таблицу setting_user
user_id | setting_id

Обращаю внимание на именование полей и таблиц и прочих сущностей, принятое в ларавел. Следуя этим соглашениям вы упростите себе создание связей.

Далее курить доку на предмет связи many-to-many

У юзера создать отношение

public function settings() {
  return $this->belongsToMany(Setting::class);
}

Теперь у пользователя вы можете получить все его настройки

$user->settings

Создать новую

$user->settings->create([...])

И т.д.

С таким уровнем я бы рекомендовал набраться опыта в офисе или где-то в работе по найму.
Лезть во фриланс с нуля - это крест на своей карьере.

Нормальные опытные люди вообще не конкурируют с индусами.