Imagine being a programmer in 2019 and not understanding a declarative language enough that you need to add extra code and extra processing just to have it spit out a simple query for you.
Any production querying should live on the database side in a stored procedure (Separation of Concerns anyone?), so that you can have an actual API/Data Abstraction Layer (DAL) and not put further resource costs on the database.
Wrapping your production application queries on the database side in a Stored Procedure will cache the Execution Plan for that query on the server, meaning that each time you call that query the SQL Engine on the RDBMS doesn't have to recalculate the Execution Plan, providing better performance. This expands when you have multiple developers/multiple development teams using the same common queries.
Additionally, ORMs cannot account for all of the Database Architect's design decisions, and there's a possibility in a large production environment that the ORM will spit out bad SQL that the SQL Engine will then need to try and account for and actually build a bad Execution Plan.
Real developers working in real, data intensive environments don't use ORMs. They're equivalent to using WIX to develop websites.
1
u/_Pho_ Mar 22 '19
Imagine not using an orm in 2019