A monthly report query generated by the application's ORM joins six tables and runs for minutes. Profiling shows it needs a rewrite the ORM's query API cannot express, while the rest of the application uses the ORM without problems. Which remediation is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
You don't tear down the whole house because one window sticks. ORMs nearly always let you drop to raw SQL or call a stored procedure for the odd query that needs it. Fix the one problem query and leave the productivity win everywhere else.
Full Explanation
When profiling isolates a single statement that the ORM cannot generate efficiently, the targeted remediation is to bypass the framework for that query only. Mainstream ORMs support native SQL queries, mapped views or stored procedure calls, so the developer can write the optimized statement, sometimes with supporting indexes, while the rest of the application keeps the productivity of generated SQL. The change is small, testable and easy to roll back. Ripping out the ORM across the whole application is disproportionate: it discards working code, adds risk to every data path and solves nothing beyond the one query that was already identified. Raising the command timeout hides the symptom; the report still consumes resources for minutes, competes with other workloads and will eventually exceed any new limit as data grows. Moving the data to a document store is a platform change that does not address the analysis, and relational reporting across six related entities is a poor fit for that model. Exam caveat: remediation can also include adding an index or adjusting fetch strategy if the ORM can express it; the stem rules that out here. Operational check: compare the old and new query plans and durations in test and confirm the report returns identical results.