From Yakov Fain's blog.

In the mid nineties, IT job market was good. PowerBuilder or Visual Basic plus SQL would get you employed in no time. Good old client/server days… Lots of mainframe programmers were easily surviving knowing nothing but Cobol and SQL (DB2).  Two programming languages was all you need.
When multi-tier architecture became hot and J2EE came into picture, all of a sudden you’d have to learn a lot more languages and technologies, for example, Java, SQL, HTML, JavaScript, XML, JSP, EJB, JMS etc. And I’ve learned all this jazz.

Five years ago the IT job market was really bad. Five years ago job postings would require knowledge of ten  different programming languages, and if you knew only nine, you could not get a job interview let alone job. At the time I’ve been working as an independent contractor, but the job market was so bad that I couldn’t find a decent contract and became a full time employee of a major bank, where I spent about two years. On Fridays, I’d send out an email to everyone in our department with a little SQL puzzle. Some of them I’ve been inventing myself, some googled up but most of them I’d take from an excellent book by Joe Celko called “SQL for Smarties” .  These emails were well received and people were responding with the answers written in SQL.
SQL was still in favor. Technical job interviews would include a couple of SQL questions. It’s hard to believe, but people knew how to find duplicates in a database table by manually writing  “group by” and “having” clauses.

How many people have read the book by Joe Celko, “SQL for Smarties”? Let me put it another way. How many people had ever written any SQL statements? Why bother, an Object-Relational Mapping  (ORM) framework like Hibernate will let me map Java class attributes to the database table columns. How nice...I'm drowning in XML now.
I never liked ORM. I trust SQL.  Surprisingly,  the young generation doesn’t mind being polyglot programmers as long as the set does not include SQL.  The popularity of this language is comparable with the popularity of Latin and Esperanto in the real world. Why? I don’t get it. SQL is a very elegant and powerful language with an excellent ROI!

Note. In the next two paragraphs I’ll be bragging, so you might want to skip them.

In 1997, I was hired for a PowerBuilder/SQL job by a small company that was developing software for telecommunications giants like South Bell.  On my first week on the project, Sarah, the co-owner of the firm was absent – she was delivering a baby. I had to wait for her as she was supposed to give me an assignment.  Someone showed me a report written as a Sybase stored procedure. This daily report would run for an hour collecting various data about activities of the field technicians. This report was poorly written - it was using several cursors that were making multiple passes through the same data set. I’ve eliminated most of the cursors by re-writing the “where” clause in the main SQL statement and applying some characteristic functions. The execution time of this report went down from an hour to under a minute. Everyone was impressed. I became a proven commodity and spent a year in this company enjoying an easy contract with high pay check till the company went belly up without paying me the final check. Talking about the power of SQL! 

Here’s one more interesting detail. When Sarah came back from her short maternity leave, someone delivered the great news to her, “Yakov modified that slow report, and now it only takes a minute to run!” She looked at me and said, “Working with SQL was not your job, but I’m not angry with you – I’m too long in this industry”.  A couple of days later, I found out that Sarah was the original author of that stored procedure and my bad behavior showed here little weakness. Customer’s interests often have lower priority than a someone’s ego, but that’s another subject.

In one of my mid-nineties jobs I met a very good programmer named Roman D. who introduced me to characteristic functions in SQL (they were described in this book).  These functions are not easy to grasp, but when you get it, your SQL will work a lot faster.   Roman was a seasoned consultant, and he shared with me an important technique for passing technical job interviews.  He’d explain characteristic functions to the interviewers, they were impressed and would extend him an offer.  I said, “Roman, nobody knows about these characteristic functions, and the chances are less than slim that someone would ask you about them during the interview.”  He smiled to me and said, “I do not wait till someone asks me about them. It’s my strong point, and I always find a way to change the subject and show these SQL tricks.”  I’ve mentioned this interviewing technique in my e-book “Enterprise Software without the BS ”.

May be one day the ORM tools will generate highly-optimized SQL, but it won’t happen any time soon, that’s for sure. Proponents of ORM tools would argue that their tools also allow manually write SQL statements in one of their XML configuration files. If this is the case, and if you are capable of writing SQL, why bother with ORM to begin with?

Let me tell you an old Jewish tale. I’ve used it already in a couple of my other articles before, but it’s applicable in so many life situations including computer programming…

A poor man comes to the rabbi complaining that his family has only one small room, many kids, and almost no money. The rabbi says, "Take all your money, buy a goat, and keep the goat in your room. Come back in a month."
"But, rabbi, we don't have enough space even for us," the man said
"Just do what I say," the rabbi replied.
A month later the man comes back complaining that the goat smells and breaks everything.
"Sell the goat and come back in a month," the rabbi tells him.
A month later the man comes back to the rabbi with flowers.
"Thank you, rabbi! We're so happy the goat is out, now we have more room and some money!"

So if you are considering bringing the ORM-goat in, think twice. Or actually, don’t – this way you may enjoy the moment of happiness when the goat will be out, and you’ll return to SQL.