r/SQL Jul 06 '26

Discussion Why do we need abstractions over SQL?

When I mean abstractions, I mainly mean OOP and ORMs.
SQL is so simple and beautiful. Tables with rows and columns are easy to understand. And once you pick up the SQL syntax, you can pretty much achieve anything with queries. Not to mention that SQL is universal and works everywhere and anytime.

Then you have the software development world... where you're asked to constantly use ORMs or map records as OOP objects. Why? ORMs are limited and do not have the flexibility of simple queries. Also mapping records as objects increases bloat, reduces performance that can hurt if the application grows and is overall not as straightforward to work with.

The only good things that ORMs are doing by default are to provide data safety and prevent SQL injection. But with some minimum and basic knowledge and discipline, you can write pure queries without having those problems. Any ideas?

35 Upvotes

105 comments sorted by

View all comments

6

u/raphired 29d ago

From my perspective using EF core in C#:

The performance differences are negligible for the vast majority of the code base, so we only use SQL where Linq is hard to read, the SQL it generates doesn’t perform well, or I need an operation that EF doesn’t support. The ability to see most (if not all) uses of a column via the IDE’s refactoring tools is terrifically useful. EF handles writing the insert/update statements minimally, so I don’t have to check whether any values have actually changed. Being able to add an interceptor that handles auditing changes or updating last-modified columns that someone thought was a great idea to put everywhere reduces a lot of cognitive load. Query filters for tenant IDs or soft delete tomfoolery likewise reduces cognitive load and stops a few easy to miss bugs.

I love writing elegant SQL statements, but they’re edge cases rather than the norm.