SQL

474 readers

1 users here now

Related Fediverse communities:

#sql on Mastodon
#postgresql on Mastodon
c/PostgreSQL on programming.dev

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

founded 1 year ago

MODERATORS

Ategon

jnovinger

Is there a programming language specifically designed for interacting with SQL databases? (lemmy.one)

submitted 8 months ago by [email protected] to c/sql

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

[–] [email protected] 1 points 7 months ago* (last edited 7 months ago)

you’ll get an easily designed solution that you can use over and over and requires minimal effort to maintain and update as the needs change

The moment it involves me having to leave the context of my workspace, go to some other workspace, abd then try and connect the dots between the two without there being any existing solutions to aid that, it's never going to be easy.

That's just a cold hard fact. There's no fluid LSP mechanism to context switch between the SQL and my backend code. Full stop.

If I have BE code that invokes a stored proc, I can't just see the definition of "wtf does that stored proc do?" From within my workspace.

I definitely can't just hit a button at this time to just switch to its definition.

Also, the fact what my DB thinks the stored proc is vs what the code says it does is always a big wrench in the gears. I despise the entire concept of "well the code defines it as this but my local db is out of date"

The concept of literally switching git branches is all it takes for my codebase to say one thing and my db to say another.

You can't reconcile that without tonnes of extra work.

And add in the fact that this problem can layer up with stored prics calling stored procs, DB schema changing...

I just am not interested in a stack where I have to maintain 2 entirely separate chains of distinct sources of truth, especially when the latter doesn't even maintain with Version Control.

just get a data expert

Like I said if you actually have a DB Engineer, use them.

But this may surprise you but, most projects just don't have one, nor can they afford one.

On smaller companies looking to cut costs, having a BE dev is necessary, but if the need for a DB Engineer can be replaced by a BE Dev just using an ORM for now, then I think it's pretty straightforward which of the two roles will be hired and the other passed on.

Until you get to a fairly large scale, actually having dedicated DB engineers simply just isn't the part of most companies strategies.

Do I wish I had another entire person who could just handle it for me?

Sure.

But it's not gonna happen if I'm not working on FAANG scale projects, I also wish I had a million dollars right now, but that's just not reality.