ORM is not a good abstraction for anything but the trivial case of a table. As soon as you want to do anything actually relational, I have yet to see an ORM layer that comes up with an efficient join.
Microsoft's Linq for SQL generates mostly OK SQL from your code. While not perfect for all complex operations (like multiple joins with aggregations), the SQL isn't horrible. For most use cases though, the SQL seems to be on par with what I would write myself. Ofcourse this is a rather vendor-specific implementation (for Microsoft SQL Server), but there are decent ORMs out there.
The biggest problem really comes when people don't understand what underlying SQL will be required for specific operations and just write code blindly. This can cause things like the famous nested-loops effect instead of efficient joins, but this is solvable trough knowing how to properly use your tool.
That being said ORMs are good at poking at small amounts of data (single or few objects), while SQL is probably the best language there is for huge set-based operations. When you are doing set-based things, not using SQL will most likely be a bad choice.
Microsoft's Linq for SQL generates mostly OK SQL from your code. While not perfect for all complex operations (like multiple joins with aggregations), the SQL isn't horrible. For most use cases though, the SQL seems to be on par with what I would write myself. Ofcourse this is a rather vendor-specific implementation (for Microsoft SQL Server), but there are decent ORMs out there.
The biggest problem really comes when people don't understand what underlying SQL will be required for specific operations and just write code blindly. This can cause things like the famous nested-loops effect instead of efficient joins, but this is solvable trough knowing how to properly use your tool.
That being said ORMs are good at poking at small amounts of data (single or few objects), while SQL is probably the best language there is for huge set-based operations. When you are doing set-based things, not using SQL will most likely be a bad choice.