Laravel: Raw SQL Queries with DB::select()

preview_player
Показать описание
If you have an SQL query, you don't have to transform it into Eloquent or Query Builder.

- - - - -
Support the channel by checking out my products:

- - - - -
Other places to follow:
Рекомендации по теме
Комментарии
Автор

I see myself increasingly using more and more complex raw queries in Laravel. As i'm getting more fluent and comfortable in SQL, i noticed that i'm shifting more and more stuff from code, to queries. The eloquent/query builder is very powerful and easy, and combining it with some RAW goodness, we can make real nice and performant stuff.

ThalisUmobi
Автор

I wouldn't build complex queries in this way. You can use the native db feature for it! Check the database view or if you need to cache these queries then a materialized view comes to play.

Views can be used on top of eloquent models. You have to only set a different table name (optionally you can add ReadOnlyTrait) to the model. You will still have all the features and benefits of eloquent (relationships, builder, etc.). Moreover, your code will be much cleaner and reusable

pperzyna
Автор

Something that usually happens to me is that I forget to include an IS NOT NULL on the deleted columns when using soft deletes.

LigurienRennrad
Автор

good advice. No need to go from Raw to Eloquent just for eloquent to generate the same sql eventually.

matrixlander
Автор

Was looking into some 'exists' queries this week. Didnt like the implementation by laravel. So I ended up chaining
Much much faster.

fiho-ohif
Автор

If your code using that returned data isn't using any eloquent methods, it is better to use raw SQL for faster query result.

RaicaBogdan
Автор

Totally agree. We shouldn’t do that for the sake of having it in eloquent format.

SaiyanJin
Автор

I was recently looking for similar subject, cause one of popular package needed (excel one) needed in it's trait to return "query" object. And yea, obviously i have huge sql to work with, with subqueries and joins etc, so i guess that there is an use for transforming sql to query. And general oop reasons

andymr
Автор

Some of the "new" developers who haven't worked much with Raw SQL prefer Eloquent, and they go mental when they see Raw SQL and they protest as Raw SQL is "WRONG" or "ANTI-PATTERN".
It seems like some of the new developers are only behind the "NEW" trends and not much aware of the technologies that they are using.
It is becoming pretty annoying to have such teammates in the team...

kickass
Автор

I generally don't try to transform massive SQL queries.

Flankymanga
Автор

Are you reading my mind? I am optimizing stuff in Laravel to get rid of subqueries. Today 😅

cardboarddignity
Автор

Chatgypitty could probably get close with some manual tweaks afterwards, but using DB facade and not using models. Converting that to use models would be excruciating

cloudergnu
Автор

im using laravel for a project, and the database colum names are not intuitive. im using laravel form requests to validate the input. is there any way that i can map the form names to database column names while creating/updating the table info, once? I want the names to be correct in the form, as it helps in generating errors with the form requests.

phoneywheeze
Автор

When I write query in select it takes 12 second while I write same query in raw it takes only 1 second . Why ?

riyadhaka__
Автор

I think this video does not really answer the question. Using DB::select when trying to "convert a raw sql to laravel's query builder" is a crutch. This problem is basically reduced to "How to use a subquery as the FROM clause" because the SELECT, WHERE, and GROUP BY clauses are very straightforward.

Laravel makes it very easy since it supports both of these signatures: ->from(Closure $table, string $alias) and ->from(Builder $table, string $alias).

For this case, I think it's more readable to use the Builder one. This means just writing the subquery as its own thing and later using it in the query.

intipontt
Автор

Ask chat gpt to convert to Eloquent 😃😃😃

mohammadimranmir
Автор

I had this opportunity like a 1-2 years ago when I resumed practicing Laravel on various projects. TBH I didn't know about eloquent at all. That was the time when I discovered it and started transforming all my raw SQL into eloquent. I was really amazed and satisfied by how seamlessly it works, shortens the code dramatically and increases the readability of the code! Like a magic🪄

sadiriy
Автор

I still do not understand why you guys use that heavy waste of time THING (Laravel)? - Oh, Yes I know why - I think because you can not be responsible on the security of the system on production environment at work right? - And if something is wrong you just say "Well, It turned out that Laravel has a problem" - not you... And if someone asks why are you using that THING - you just simply say "Well, it is popular, easy and ready to go... and you just build and not wasting a time on building a new frame" ... Really? You are not wasting a time? ... I don't think so... <<< That's how the legendary army of "LaraDevs" was created >>>

irakligzirishvili