this post was submitted on 29 Mar 2024
14 points (88.9% liked)

SQL

469 readers
1 users here now

Related Fediverse communities:

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
Ategon@programming.dev
jnovinger@programming.dev
14
Is there a programming language specifically designed for interacting with SQL databases? (lemmy.one)
submitted 7 months ago by veer66@lemmy.one to c/sql@programming.dev
43 comments fedilink hide all child comments
 

Is there a programming language specifically designed for interacting with SQL databases that avoids the need for Object-Relational Mappers (ORMs) to solve impedance mismatch from the start?

If such a language exists, would it be a viable alternative to PHP or Go for a web backend project?

you are viewing a single comment's thread
view the rest of the comments
[–] pixxelkick@lemmy.world 1 points 7 months ago (1 children)

I don't see why I'd do that over

db.Users
    .Where(u => u.UserId == 10)
    .ToListAsync();

Which will produce pretty much the exact same sql under the hood but be 100x easier to read, maintain, and debug.

[–] RonSijm@programming.dev 1 points 7 months ago (1 children)

I don’t see why I’d do that

Because just Dapper will perform a lot better executing raw sql queries than EF having to go through an entire expression tree builder.

Anyway, I wasn't saying that that example is a better way than doing it with EF, I was just going over your points where you mentioned that with raw SQL it's just all unreferenced magic strings with no references to tables or columns. And that you can't find where anything is used.

So that's just to explain - if you write your sql inside code in the poorest possible way - yea, you're gonna have a poor experience. But if you want to write raw sql instead of using an ORM, it's pretty easy to negate all those downsides about not having references

[–] pixxelkick@lemmy.world 1 points 7 months ago

Because just Dapper will perform a lot better executing raw sql queries than EF having to go through an entire expression tree builder.

I'd like to see some benchmarks on truly how much this difference matters when running on the cloud.

I expect latency alone between the App<->Db will dwarf whatever microseconds your raw sql would save that it's hard to distinguish from the chaos of latency variance.