5 ms·

Why is ORM better than just writing out SQL code? It just adds an extra layer of indirection, and another layer of processing that can go wrong. And when thing

Why is ORM better than just writing out SQL code? It just adds an extra layer of indirection, and another layer of processing that can go wrong. And when things go wrong, you have to dig down to the SQL level to understand it. But the table names are all mangled, which might further add to the complexity of debugging it.

deleted 6y ago
[deleted]
geocar 6y ago
What if things don’t go wrong? One way that it is better is that it might be a better abstraction. If so, it would be possible to implement just these methods to target an in-memory or on-disk store without the SQL — and get a dramatic performance improvement. But because data management requires a lot of disciplines and it is easier to test “is this is a better abstraction?” if by creating these kinds of abstractions on abstractions. Some of them will evolve into “noSQL” but most fail because SQL has a first-movers advantage and they aren’t enough better to warrant further investment. Better may be possible but too few people can afford the luxury of exploring language design — and those that can are scared off easily; People who make bad investments worry about their fellow human and try to prevent them from making the same mistake; and so you worry about what happens when it goes wrong, which is why I say, “what if it doesn’t?”
desas 6y ago
Do people actually use ORM to avoid writing SQL (there are other patterns for that), or do they use it because it saves writing the boilerplate of object hydration?
- braisdom 6y ago
  It is a more efficient way to data analysis, SQL is just one way, Java is another way, and ObjectiveSQL, instead of using Java instead of SQL, let's forget about SQL
BorisTheBrave 6y ago
The biggest deal for me is type safety (I use C#'s EntityFramework). While composing the ORM queries, I get the benefit of static verification, autocompletion, and can avoid the common boilerplate of joins. When reading code, find-references and so on work.

deleted 6y ago

[deleted]

geocar 6y ago

What if things don’t go wrong? One way that it is better is that it might be a better abstraction. If so, it would be possible to implement just these methods to target an in-memory or on-disk store without the SQL — and get a dramatic performance improvement. But because data management requires a lot of disciplines and it is easier to test “is this is a better abstraction?” if by creating these kinds of abstractions on abstractions. Some of them will evolve into “noSQL” but most fail because SQL has a first-movers advantage and they aren’t enough better to warrant further investment. Better may be possible but too few people can afford the luxury of exploring language design — and those that can are scared off easily; People who make bad investments worry about their fellow human and try to prevent them from making the same mistake; and so you worry about what happens when it goes wrong, which is why I say, “what if it doesn’t?”

desas 6y ago

Do people actually use ORM to avoid writing SQL (there are other patterns for that), or do they use it because it saves writing the boilerplate of object hydration?

braisdom 6y ago
It is a more efficient way to data analysis, SQL is just one way, Java is another way, and ObjectiveSQL, instead of using Java instead of SQL, let's forget about SQL

BorisTheBrave 6y ago

The biggest deal for me is type safety (I use C#'s EntityFramework). While composing the ORM queries, I get the benefit of static verification, autocompletion, and can avoid the common boilerplate of joins. When reading code, find-references and so on work.