Например MVP собирается из говна и палок, чтобы показать идею

В том что он попросил перевести этот код - значит ему надо. Я считаю это правильным. а ты пытаешься научить его плохому.

почему плохому сразу?

Может у него супер высоконагруженный проект, а он решил QueryBuilder по незнанию использовать?! :)

почему ты решил что только твой метод верный?

а все остальные должны делать только как ты решил

и все остальные подходы не имеют места на сущестование

Смотри аналогия. Идет человек - хочет в туалет. Ищет туалет я ему показываю дорогу. А ты приходишь и говоришь, да зачем если можно прям на дороге насрать.

Да и с чего ты взял что он новичек

Ну ты прям аналогий мастер. Я тебе таких могу кчу привести не в твою пользу

потому что использует QueryBuilder

У. Кайф. Тогда в этом чате все новички

Имеется виду чистый query builder

без моделей

и пришел сюда с SQL запросом

значит откуда то все это переносит

Ты как будто доктор хауса не смотрел :)))

Ладно, публично признаю, что  @Med1c84  во всем прав, я бы в своих проектах такой SQL не пропустил по ряду причин, многи из них совпадают с теми, что ты озвучил. Вопрос был чисто на рассуждение и зависил исключительно от типа проекта и его долгосрочности (Для MVP мне было бы лень переносить на QB). 🤝

Да и что с меня джуна взять то?! Век живи век учись

В догонку треда о sql raw-queries vs. query-builder. @butschster @Med1c84

Если мои запросы выходят за рамки 2-5 строк понятного query builder’а или простого обращения к связям модели - я пишу чистый sql запрос. Sql унифицирован и тебе не нужно думать о n+1 всяких orderBy или where из query-builder.

Поддерживаю мысль Димы Кожанова, о том что нужно соблюдать стайл-гайд(я сам после того как написал большой sql запрос, перевожу его на query-builder), но(!) никто не застрахован от изменений в api query-builder’а и поломки всего запроса из-за одного chain’а. И если проект высоконагруженный то проще и быстрее* писать запросы сразу на чистом sql