4 ms·

Abstraction is good, but I think the problem is that ORM is not a good abstraction for anything but the trivial case of a table. As soon as you want to do anyth

by seldo 17y ago

Abstraction is good, but I think the problem is that 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. The reason, say, C++ is a good abstraction for machine code is because it simplifies what's going on to the point that you can write something very complex in fewer lines of code, allowing it to fit into the human brain better. I'm willing to be shown examples to the contrary, but ORM layers don't simplify or compress relational queries, they just change the syntax to something more "object-y". So maybe my point is that abstraction is good, but ORM isn't really abstraction.

trezor 17y ago
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.

by seldo 17y ago

trezor 17y ago

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.