4 ms·

> 1. modern programming frameworks all abstracted away SQL because people found it hard to understand No. Not because it's complicated. Because they wanted hig

> 1. modern programming frameworks all abstracted away SQL because people found it hard to understand No. Not because it's complicated. Because they wanted higher level facilities for getting/setting data. In other words, they put in abstraction because abstraction is good, not because they are dumb.

dave_au 17y ago
There's probably two sets of people at work in the statement. The people who made the frameworks would require a good understand as well as the idea that an abstraction might make life easier. The side effect is that if you create a good enough abstraction you'll get people who can handle the abstraction but are a little shakey when dealing with what is abstracted. See, you can both be right :)
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.
kragen 17y ago
Although SQL sucks, it is a higher-level facility for getting and setting data than ORMs are. ORMs don't exist to abstract away SQL; that is counterproductive. ORMs exist so you can store your objects in a relational database, which is not a problem you can solve in SQL. I suspect that a big part of the problem with SQL is that it's too abstract: it is both hard to predict how fast a query will run and hard to predict whether the query will continue to run fast as the database changes. A big part of the appeal of things like memcached and Redis is that their performance is not only fast, but also predictable.
- gnaritas 17y ago
  > it is a higher-level facility for getting and setting data than ORMs are No, it's a higher level facility for querying data when you want different result sets back randomly, it sucks most common operations of inserting or updating data. Forcing me to write a very long statement to insert a row isn't in any way more abstract that saying anObject.save(). SQL continually forces one to write the same boring code over and over. As soon as you start automating the generation of the boring bits, you've started to build an ORM. ORMs exist because programmers get tired of writing the same code again and again. While SQL is good at what it does, it doesn't do the thing programmers need done most, which is store data structures easily without making them write a bunch of mapping code to translate it first. SQL isn't confusing, it's just frustratingly boring and repetitive.
  - kragen 17y ago
    In the comment you are replying to, I said, "ORMs exist so you can store your objects in a relational database, which is not a problem you can solve in SQL." It sounds like you're saying the same thing?

dave_au 17y ago

There's probably two sets of people at work in the statement. The people who made the frameworks would require a good understand as well as the idea that an abstraction might make life easier. The side effect is that if you create a good enough abstraction you'll get people who can handle the abstraction but are a little shakey when dealing with what is abstracted. See, you can both be right :)

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.

kragen 17y ago

Although SQL sucks, it is a higher-level facility for getting and setting data than ORMs are. ORMs don't exist to abstract away SQL; that is counterproductive. ORMs exist so you can store your objects in a relational database, which is not a problem you can solve in SQL. I suspect that a big part of the problem with SQL is that it's too abstract: it is both hard to predict how fast a query will run and hard to predict whether the query will continue to run fast as the database changes. A big part of the appeal of things like memcached and Redis is that their performance is not only fast, but also predictable.

gnaritas 17y ago
> it is a higher-level facility for getting and setting data than ORMs are No, it's a higher level facility for querying data when you want different result sets back randomly, it sucks most common operations of inserting or updating data. Forcing me to write a very long statement to insert a row isn't in any way more abstract that saying anObject.save(). SQL continually forces one to write the same boring code over and over. As soon as you start automating the generation of the boring bits, you've started to build an ORM. ORMs exist because programmers get tired of writing the same code again and again. While SQL is good at what it does, it doesn't do the thing programmers need done most, which is store data structures easily without making them write a bunch of mapping code to translate it first. SQL isn't confusing, it's just frustratingly boring and repetitive.
- kragen 17y ago
  In the comment you are replying to, I said, "ORMs exist so you can store your objects in a relational database, which is not a problem you can solve in SQL." It sounds like you're saying the same thing?