I'll give an example. At my previous company there was a program where you basically select a start date, select an end date, select the system and press a button and it reaches out to a database and pulls all the data following that matches those parameters. The horrors of this were 1. The queries were hard coded.

They were stored in a configuration file, in xml format.
The queries were not 1 entry. It was 4, a start, the part between start date and end date, the part between end date and system and then the end part. All of these were then concatenated in the program intermixed with variables.
This was then sent to the server as pure sql, no orm.
Here's my favorite part. You obviously don't want anyone modifying the configuration file so they encrypted it. Now I know what you're thinking at some point you probably will need to modify or add to the configuration so you store an unencrypted version in a secure location. Nope! The program had the ability to encrypt and decrypt but there were no visible buttons to access those functions. The program was written in winforms. You had to open the program in visual studio, manually expand the size of the window(locked size in regular use) and that shows the buttons. Now run the program in debug. Press the decrypt button. DO NOT EXIT THE PROGRAM! Edit the file in a text editor. Save file. Press the encrypt button. Copy the encrypted file to any other location on your computer. Close the program. Manually email the encrypted file to anybody using the file.

you are viewing a single comment's thread
view the rest of the comments

[–] pokexpert30@jlai.lu 2 points 23 hours ago* (last edited 23 hours ago) (1 children)

Orm are a way to handle seamlessly the model aspect of a codebase. But I agree.

My first big project (Symfony, with doctrine orm), we had to have several SQL requests made by hand due to the complexity of the databases here and there. So we were kept on our toes when it came to database knowledge haha

[–] expr@programming.dev 3 points 18 hours ago

Except it's not seamless, and never has been. ORMs of all kinds routinely end up with N+1 queries littered all over the place, and developers using ORMs do not understand the queries being performed nor what the optimal indexing strategy is. And even if they did know what the performance issue is, they can't even fix it!

Beyond that, because of the fundamental mismatch between the relational model and the data model of application programming languages, you necessarily induce a lot of unneeded complexity with the ORM trying to overcome this impedance mismatch.

A much better way is to simply write SQL queries (sanitizing inputs, ofc), and for each query you write, deserialize the result into whatever data type you want to use in the programming language. It is not difficult, and greatly reduces complexity by allowing you to write queries suited to the task at hand. But developers seemingly want to do everything in their power to avoid properly learning SQL, resulting in a huge mess as the abstractions of the ORM inevitably fall apart.