What ORMs have taught me: just learn SQL (2014)
Ten years ago, there was a blog post every other week bemoaning ORM&#x27;s.  Ten years ago, those posts often had merit.<p>In 2016, this sentiment is outdated.  A few points:<p>1. If you think that using an ORM means you don&#x27;t have to learn SQL, then you&#x27;re going to have a bad time.  This is where most of the bad press originates... from people who never really learned SQL <i>or</i> their chosen ORM.  An ORM provides type checking at your application layer, and typically better performance (unless you plan on hand-rolling your own multi-level cache system).  But you still must understand relational database fundamentals.<p>2. If you&#x27;re not using an ORM, then you ultimately end up writing one.  <i>And doing a far worse job than the people who focus on that for a living.</i>  It&#x27;s no different from people who &quot;don&#x27;t need a web framework&quot;, and then go on to re-implement half of Rails or Spring (without accounting for any CSRF protection).  Learning any framework at a professional level is a serious time investment, and many student beginners or quasi-professional cowboys don&#x27;t want to do that.  So they act like their hand-rolled crap is a badge of honor.<p>3. Ten years ago, it was a valid complaint that ORM&#x27;s made custom or complex SQL impossible, didn&#x27;t play well with stored procedures, etc.  But it&#x27;s 2016 now, and this is as obsolete as criticizing Java by pointing to the EJB 2.x spec.  I can&#x27;t think of a single major ORM framework today that doesn&#x27;t make it easy to drop down to custom SQL when necessary.