4 ms·

> My particular bugbear is working with people who refuse to learn SQL as if it's some arcane bit of weirdness on a par with machine code. They've only ever use

> My particular bugbear is working with people who refuse to learn SQL as if it's some arcane bit of weirdness on a par with machine code. They've only ever used ORMs and have no idea how to actually talk to their data. /rant Lol this is me. People who write their SQL from scratch confuse me, I'm like, just use the ORM and then everything's consistent! :P

spotman 11y ago
The real trick is to have a deep understanding of SQL before you use an ORM so that you know exactly what you are asking the ORM to ask the database to do. Otherwise you will never be able to really understand what is going on and will not be able to optimize a complex app that needs to be performant at scale. Learning both has its advantages and I think an ORM can indeed speed up development, most especially for the prototyping phase.
- deleted 11y ago
  [deleted]
sanderjd 11y ago
Learning about the relational model and its mapping in SQL is a really major level-up that you should really consider getting under your belt! I used to do a lot of hiring of Rails developers, and always believed (though admittedly not scientifically enough) that the best differentiator between "sorta productive" and "capable of fully independent work" was an understanding of how AR maps to SQL and the ability to know when (and how best) to drop down into writing queries directly.
ericd 11y ago
You might want to look at some of the SQL that your ORM is generating for your important queries... Because a lot of times, odds are it's much, much less efficient than it could be. I've seen ActiveRecord create some head scratchers.
- seivan 11y ago
  There is a big difference between ActiveRecord pre and post Arel. Give it another go if you haven't seen Arel in action.
ChrisDutrow 11y ago
A developer who doesn't understand SQL could be a little dangerous because they might not understand data structures and big-O concepts (sets, hash tables, etc..). I don't think someone needs to be a wizard with the syntax, but they need to understand what the database is doing. Otherwise they could write something that won't handle load under real world use.
- douche 11y ago
  One of the things I like about the .NET Linq-to-SQL and EF ORMs is that it's pretty easy to plug into them and get them to dump the actual SQL that they are executing. Still, you really need to have a good handle on the difference between operations that build up the query, without executing it, and those that pull the data back from the database. Also understanding what code constructs that the ORM is capable of translating into SQL statements.
  - ChrisDutrow 11y ago
    .NET is actually the framework that gave me such a bad taste for frameworks. It's important to note that my experience with it is from around 2010-2012 though so it could have gotten much better since. The ORM in particular would sometimes cause me to write very inefficient queries. If I understood the ORM better, I probably could have avoided this, but I found it much easier to write a data layer that ran SQL queries directly and supplied the other layers with simple JSON-like objects.
    - marcus_holmes 11y ago
      me too. EF was what caused me to (finally) dump the entire .Net ecosystem and start learning again from scratch with Linux.
      - ChrisDutrow 11y ago
        Yeah, most of the projects I've been working on lately wouldn't be possible with a licensed operating system. For me, working with linux is very difficult, but the capability far outweighs the difficulty. I don't catch on easily to concepts, commands, and multiple steps of such an advanced tool.
nissimk 11y ago
Don't trade consistency for power. If you know sql, you can answer questions about your data without writing a program, by just executing queries in a database UI. This ad-hoc querying is far more powerful than any other debugging technique for many classes of problems.

spotman 11y ago

The real trick is to have a deep understanding of SQL before you use an ORM so that you know exactly what you are asking the ORM to ask the database to do. Otherwise you will never be able to really understand what is going on and will not be able to optimize a complex app that needs to be performant at scale. Learning both has its advantages and I think an ORM can indeed speed up development, most especially for the prototyping phase.

deleted 11y ago
[deleted]

sanderjd 11y ago

Learning about the relational model and its mapping in SQL is a really major level-up that you should really consider getting under your belt! I used to do a lot of hiring of Rails developers, and always believed (though admittedly not scientifically enough) that the best differentiator between "sorta productive" and "capable of fully independent work" was an understanding of how AR maps to SQL and the ability to know when (and how best) to drop down into writing queries directly.

ericd 11y ago

You might want to look at some of the SQL that your ORM is generating for your important queries... Because a lot of times, odds are it's much, much less efficient than it could be. I've seen ActiveRecord create some head scratchers.

seivan 11y ago
There is a big difference between ActiveRecord pre and post Arel. Give it another go if you haven't seen Arel in action.

ChrisDutrow 11y ago

A developer who doesn't understand SQL could be a little dangerous because they might not understand data structures and big-O concepts (sets, hash tables, etc..). I don't think someone needs to be a wizard with the syntax, but they need to understand what the database is doing. Otherwise they could write something that won't handle load under real world use.

douche 11y ago
One of the things I like about the .NET Linq-to-SQL and EF ORMs is that it's pretty easy to plug into them and get them to dump the actual SQL that they are executing. Still, you really need to have a good handle on the difference between operations that build up the query, without executing it, and those that pull the data back from the database. Also understanding what code constructs that the ORM is capable of translating into SQL statements.
- ChrisDutrow 11y ago
  .NET is actually the framework that gave me such a bad taste for frameworks. It's important to note that my experience with it is from around 2010-2012 though so it could have gotten much better since. The ORM in particular would sometimes cause me to write very inefficient queries. If I understood the ORM better, I probably could have avoided this, but I found it much easier to write a data layer that ran SQL queries directly and supplied the other layers with simple JSON-like objects.
  - marcus_holmes 11y ago
    me too. EF was what caused me to (finally) dump the entire .Net ecosystem and start learning again from scratch with Linux.
    - ChrisDutrow 11y ago
      Yeah, most of the projects I've been working on lately wouldn't be possible with a licensed operating system. For me, working with linux is very difficult, but the capability far outweighs the difficulty. I don't catch on easily to concepts, commands, and multiple steps of such an advanced tool.

nissimk 11y ago

Don't trade consistency for power. If you know sql, you can answer questions about your data without writing a program, by just executing queries in a database UI. This ad-hoc querying is far more powerful than any other debugging technique for many classes of problems.