I have the opposite view. I find ORMs annoying and obscure, and I think they introduce duplicated code.
If you need to run a certain query in multiple places, you need to repeat the same ORM expression or refractor it into a function. I find much better to have a module with all my SQL queries as strings. That way whenever I need to run a query I reference it from there. Of course it helps to use meaningful names.
This approach has a lot of advantages over ORMs:
* you know exactly what gets executed
* automatic DRY code
* the names of the SQL queries in the code are self-explanatory and the reader doesn't have to parse the ORM expression every time
Schema definitions are in standalone SQL files, as well as my migrations.
The only disadvantage is that it may be difficult to switch to a different database system, but that is not a problem for us.
Your argument does not stand up. I can have a file full of ORM sql fragments the same as you file of strings. And I can compose mine together safely and more flexibly than strings.
Have you tried Python's SQLAlchemy, the ORM parent posts are praising? The `sqlalchemy.sql` module is awesome and pretty much maps 1:1 to raw SQL.
Composing SQL expressions using this library instead of using string interpolation/concatenation has several advantages:
* DRY and composition
* safety
* portability (if you have switch the underlying DBMS)
Often the result is as good or better than my raw SQL. The fact that Python has an amazing REPL makes the process pretty much like testing queries in the database prompt but with less cognitive switch between languages.
In the end it is a matter of taste, but I have to agree with parent posts, SQLAlchemy raises the bar for other ORMs.
> I find much better to have a module with all my SQL queries as strings.
But you can't compose them, so there is a lot of duplication. Also, how would you handle dynamic filters and columns? Concatenating strings? That seems error prone. At least a nice query builder would be useful, but then the whole just write sql thing falls apart.
Hahaha, wow! That’s just about the most awful thing I’ve ever heard. If you ever find yourself sitting across a table from an interviewer, I would definitely recommend not including this little tidbit in the conversation.
If you need to run a certain query in multiple places, you need to repeat the same ORM expression or refractor it into a function. I find much better to have a module with all my SQL queries as strings. That way whenever I need to run a query I reference it from there. Of course it helps to use meaningful names.
This approach has a lot of advantages over ORMs: * you know exactly what gets executed * automatic DRY code * the names of the SQL queries in the code are self-explanatory and the reader doesn't have to parse the ORM expression every time
Schema definitions are in standalone SQL files, as well as my migrations.
The only disadvantage is that it may be difficult to switch to a different database system, but that is not a problem for us.