ORM. Получали и изменяли данные, работая с ним только. Знаю конечно, что есть и стандартные запросы типа "DB::table('users')->select(...)->where(...)". Так вот, вопрос в том, что лучше использовать в первую очередь и от чего зависит выбор использования той или иной методики в этом месте?
Использование фасада db пишет что будет быстрее работать , в некоторых случаях , затем больше выбора при написании запроса , а использование orm так же приемлемо, тут больше надо смотреть на объём сущности и количество колонок
от задачи зависит, в некоторых случаях бд быстрее, но и в некоторых опаснее
Если у тебя есть eloquent модель для таблицы используй её, фасад DB не даёт вообще никаких преимуществ, ни в производительности ни в удобстве выборки. И там и там одно и тоже под капотом.
Если сущность большая, то тут не про способ работы с ней надо выбирать, а анализировать, как так получилось, что она стала большой. Значит, плохо распилили, засунули данные по принципу "если это юзер передает, то пусть будет в юзере, чо". С таким подходом хоть PDO напрямую использовать, все равно ничего не поможет.
Конкретно Connection (которому DB запросы делегирует) быстрее елки, естественно. Там нет гидрации, нет рефлексии (которую Тейлор в последних версиях напихал еще больше), нет резолва отношений и построения запроса. Чисто сырой запрос написал и напрямую (почти) в драйвер засунул.
Это не тот пример кода, который автор скинул
Какая разница. qb все равно быстрее елки. Хз зачем с этим спорить.
Только при условии, что ты сырой запрос прокинешь. С тем же успехом можно использовать pdo. Разницы 0, кроме того, что драйвер либо будет юзаться либо нет. Но без построения запроса тебе постановка драйвера ничерта не даст, потому что для разных СУБД разные запросы.
Еще раз. Можешь даже побенчмаркать. Попробуй достать что-то (хотя бы 10 сущностей) через qb и сделай то же самое через елку, которая должна гидрировать все 10 сущностей в твою модель, отношения зарезолвить, атрибуты и прочую фигню.
Я уже бенчмаркил это на сотняк тысяч строк. Если ты делаешь мутаторы для модели, то тебе по определению не подходит элоквент, либо ты будешь преобразовать сырые данные после выборки, что одинаково скажется на производительности. Отношения резолвятся элоквентом в рантайме через лейзи. А если ты делаешь запрос с with, то по факту у тебя создаётся два запроса, которые в сумме выполняется с той же скоростью. Так что не нужно выдумывать как что работает, если ты сам не проверял, а просто прочёл где-то.
Чисто простой бенчмарк встроенным логером запросов: Eloquent (Ticket::all()): [2022-05-13 05:09:42] local.INFO: select * from "tickets" where "tickets"."deleted_at" is null [[],18.07] Connection (DB::table('tickets')->get()): [2022-05-13 05:11:49] local.INFO: select * from "tickets" [[],12.46] Записей в таблице было 30 штук.
Обсуждают сегодня