Hacker News Reader

Comment by ciconia | Hacker News Reader

I've been slowly transitioning from using an ORM to just plain SQL. It's so much simpler. Less magic, more explicitness, and more control. Also, much better performance. I think the thing is to construct your model around the different queries you need to perform. In many cases, especially a CRUD-type situation, you'll end up with 10-20 different SQL queries, and that's it.

View on HN

Once you break free of ORM’s I find the code so much simpler to maintain.

Here’s the query(typically multiple different subqueries and return types), here’s the params, give me all the data back and something like Dapper in .net is an absolute godsend to convert it.

The code is simple to maintain until the database changes. Then you will experience the pain of SQL

I’ve experienced what you’ve mentioned before, ORM or not you have issues if you’re shuffling the schema around.

Cool.

It would be great if there was a compiler that would check your SQL queries against the schema, and you could even refactor a column name to update both the schema and the queries.

Microsoft SSDT (SQL Server Data Tools), but I think it only works against Microsoft SQL Server

https://learn.microsoft.com/en-us/sql/ssdt/sql-server-data-t...

Data schema changes are difficult, almost regardless of technology - it's been an issue for me from relational dbs to OpenAPIs. gRPC is easier as long as you obey the migration rules, but those impose tight restrictions on what you can change

By the time you really needs to change your database, updating your queries will be the easiest part, compared to reviewing the semantic changes and the data migration.

Reply on news.ycombinator.com