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?
I’m curious under what condition an ORM impacts scaling at all.
ORMs merely generate a SQL query to run on the DB, then serialize the data it gets back, how your application svales should be unimpacted by using an ORM.
I’d assume if somehow it’s impeding scaling then the query itself was structured poorly, or that particular ORM was very poor.
A good ORM should be able to generate the sql query in microseconds, the actual DB query time should be typically like 99% of the response time for your API, which the ORM has no bearing on.
The SQL queries I’ve seen almost every ORM create are highly inefficient compared to a good query designed by hand. That’s where I’ve always seen the delay get introduced. You end up spending lots of cycles on the query so the delay looks like it’s within the DB but when replaced by a custom query the bottleneck goes away. Quite often a quick fix is replacing the query with a store procedure or view and letting the devs work off of that.
I have to just respectfully disagree. Perhaps you had an actual database engineer on your team who was in charge of the sql (in which case 100% yes absolutely use sql!)
But typically backend devs aren’t database engineers and they have no idea how to compose a good sql query, let alone how to optimize it or test its execution plan.
I’ve seen way way more absolute clusterfuck garbage queries that take way too long to run that were hacked together by BE devs.
Views are fucking awful imo. It’s yet another entire layer of abstraction that deeply obfuscates what is actually running and/or happening.
The entire principle of shit outside my codebase that I can inspect with my LSP causing side effects to my logic is just a nightmare to maintain.
The moment you can have the exact same application behave differently purely because different stuff was or was not put on the db it was pointed at, it’s an absolute cluster fuck to maintain.
Stored Procedures only should be reached for under one circumstance imo, and that’s when you need to use recursion on your DB.
IE if you have perhaps a parent/child self FKd table to create a hierarchy tree with unknown depth… You’d want to traverse it recursively which likely would want a stored proc.
But aside from that, I just can’t get behind breaking up the backend into effectively having 2 distinct layers of truth to its behavior.
I want all my codebase in one place, and in one language, under one language, through a single LSP.
I have had Database Engineers and done it myself. If you run any ORM created SQL queries through a profiler and look at the execution plan you’ll see it’s an absolute mess. That’s why I said it doesn’t scale. Sure it’s good for small things but I’m working on projects that have millions or rows and multiple joins. At that scale it just starts to fall apart. Having good raw queries will beat out an ORM every time at scale and that’s why I hate them. You want to use it for a small quick project, go for it. You’re trying to work at enterprise scale, get a DBA to make you actual queries.